Re: user manual code example race condition

Alan Ruttenberg <[email protected]>
Newsgroups gmane.editors.j.devel
Message-ID <CAFKQJ8moxqxMM_9mJnk-x25tygnvxt9fu6sXaVU5Aj-dr_uNKg__17333.6852387123$1552421532$gmane$org@mail.gmail.com>
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 <[email protected]> wrote:

>
>
> > On Mar 11, 2019, at 21:47, Alan Ruttenberg <[email protected]>
> 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."
>
>
>
>
>
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.