user manual code example race condition

[Mark Evenson]

> On Mar 11, 2019, at 21:47, Alan Ruttenberg <alanruttenberg at gmail.com> wrote:
> 
> I haven't looked at this code before, but in looking now, I am confused.
> Interpreter is intended to be a singleton, right? (that's what the comment says, as well as what is suggested by the use of the static interpreter variable.).
> In that case why would you want to createInstance to ever return null? 
> Why isn't there just a single synchronized getSingleton() (call it getInterpreter if you want) method, which either returns returns the existing interpreter, or creates and initializes a new one and returns it.

My current take on the code is that createInstance() returns null due to there
being three different code paths for initialization, so the “getInstance()
calls create” can’t be wrapped in a single method.

The three different kinds of creation of the interpreter are:

  1) createInstance() for “embedded" uses
  2) createDefaultInstance() for bringing up the REPL
  3) createJlispInstance() for use in the J editor 

Each initialization path populates the static reference for the Interpreter
singleton, and then proceeds to mutate the necessary state for its purposes.
As such, the mere existence of the interpreter reference does not mean that all
the necessary mutation has completed.  In lieu of a proper semantic for having
finished creation, each code path starts by checking to see if there is a value
for interpreter, punting with a null value if this is not the case with the
following stanza:

        if (interpreter != null)
            return null;

This is all very suboptimal from a user perspective, as getting a null from a call to
create expecting the caller to handle the error is just wrong.  

Still thinking about how to simplify this…



-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."