Re-entrant and multi-entrant ABCL calls

[Mark Evenson]

> On Apr 20, 2018, at 11:10, Blake McBride <blake at mcbride.name> wrote:
> 
> Greetings,
> 
> Does ABCL safely support re-entrant and multi-entrant calls?  What I mean by that is the following:
> 
> Re-entrant:  on a single OS thread - my Java program calls into ABCL, then ABCL calls into my Java application, and then the Java application calls back into ABCL.  So the stack has Java, ABCL, JAVA, and then ABCL again.
> 
> Multi-entrant:  my Java application has many threads.  One of my threads calls into ABCL.  Then, while one thread is still in ABCL, another thread evokes ABCL.  So now we have two calls into ABCL by two independent Java/OS threads running at the same time.
> 
> I understand the typical problems associated with application-level shared variables.  This is expected.  The question revolves around ABCL's internals.  I presume ABCL would have some shared data that is internal to ABCL.  That's what I am unclear about.  ABCL would have had to be designed for these scenarios from the ground up.
> 
> This is a little hard to test because if it can't always correctly handle these situations, it may not become clear until certain scenarios arrive.  It may be hard for any "test" program I write to cause those scenarios, so I thought this may be a known answer.


As long as one is referencing the org.armedbear.lisp.Interpreter singleton for
the calls into ABCL, everything should work fine.  Most of the logic can be
understood by studying what [LispThread.java][1] does to mark global/local
special variables, and how each Java thread is associated with a LispThread
call stack.

[1]: https://gitlab.common-lisp.net/abcl/abcl/blob/master/src/org/armedbear/lisp/LispThread.java#L55

How exactly are you calling into ABCL from Java?  A snippet of code would be
useful.




-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."