For Groovy-scripts you need to know that each instance of a script has a
Binding to store variables in it and that may cause re-entrance or
concurrency issues if you dont create a new script instance for each call.
Wolfgang
Am 20.04.2018 um 11:21 schrieb Blake McBride:
Greetings,
Does Groovy 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 Groovy,
then Groovy calls into my Java application, and then the Java
application calls back into Groovy. So the stack has Java, Groovy,
JAVA, and then Groovy again.
Multi-entrant: my Java application has many threads. One of my
threads calls into Groovy. Then, while one thread is still in Groovy,
another thread evokes Groovy. So now we have two calls into Groovy 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
Groovy's internals. I presume Groovy may have some shared data that
is internal to Groovy. That's what I am unclear about. Groovy 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.
Thanks!
Blake McBride
