user manual code example race condition

[Mark Evenson]

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