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." > > > > > > >