user manual code example race condition

[Alan Ruttenberg]

Wasn't quite clear. I'm assuming that there are three constructors for a
singleton and that they are incompatible - otherwise why not have one
method?
If I'm wrong about them being incompatible, then have only a single method
and move the variance to another method.

I suggested exception because if one has already been created, and you ask
for a now incompatible one, it should be an error. Calling the successful
getSingleton again should succeed.

I'm assuming the getSingleton method(s) are synchronized on the same object
(the Class in this case).

The advantage over the old way is that there isn't a race condition.

Actually, I'm not sure why only one interpreter is allowed. An alternative
would be to have separate createInterpreter, getDefaultInterpreter or
better, just use new to get a private interpreter instead of having a
createInterpreter.

createInterpreter/new always succeeds and returns a non-global interpreter
you need to keep track of yourself. getDefaultInterpreter either returns
the static interpreter or creates, stores, and returns it.

Having a createXXX that returns nil and sometimes returns an interpreter
makes no sense to me.

If we land up refactoring, I'd also propose we move the j stuff to a
separate class.

On Wed, Mar 13, 2019 at 4:15 AM Mark Evenson <evenson at panix.com> wrote:

>
>
> > On Mar 12, 2019, at 21:10, Alan Ruttenberg <alanruttenberg at gmail.com>
> wrote:
> >
> > 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.
>
> This doesn’t smell good to me.
>
> One should be able to have multiple references to a singleton, as long as
> there
> is only one singleton.  Consider the use of ABCL in a Java Servlet context
> where each instance of the servlet is processing a separate, parallel
> request.
> Each such Servlet begins its lifecycle by getting a reference to the
> singleton
> ABCL instance, and then calling into ABCL to service the request.
>
> Maybe you meant “three create singleton methods, synchronized”?  This is
> similar to what we have now, using an exception rather than returning a
> null on
> failure.  This would be a breaking change for existing users of the
> interface,
> as they would have to change their code to deal with the exception (unless
> we
> throw something that inherits from RuntimeException which would be even
> worse).
> Philosophically, Java exceptions should not be used for anticipated
> failures,
> as they are not potentially restartable like Common Lisp conditions.
>
>
> --
> "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/20190313/dc10d6f8/attachment.html>