user manual code example race condition

[Alan Ruttenberg]

Ok,
3 getSingleton methods, one for each case, synchronized.
First one wins. Subsequent ones throw an exception, since you can't have
more than one.

On Tue, Mar 12, 2019 at 2:28 PM Mark Evenson <evenson at panix.com> wrote:

>
>
> > 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."
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20190312/aba2eedf/attachment.html>