Open radeusgd opened 1 year ago
I'm implementing some synchronization primitives in #7072 using Java and callbacks and then inside of such synchronized methods the execution context information gets reset, leading to invalid results in my computations.
I will add workarounds for this, but I think the current behaviour is incorrect and not intuitive.
If we have to keep it, we at least need to very carefully document this oddity somewhere.
Currently State
is passed as an argument throughout the Enso interpret execution. Such argument is obviously lost whenever a callback to and from polyglot call is made. To fix that we would need to keep state as thread local - either as a value in EnsoContext
or as real ThreadLocal
variable.
We should use ContextThreadLocal to store the State
per EnsoContext
and per thread.
Bumping this issue as I ran into it again when working on #10609 - I was surprised why a State
read was not finding the value that I was sure is there, and I found out it was because of this bug.
Whenever I call an Enso callback from within a polyglot call (i.e. I pass an Enso callback to a Java code as
Function<A,B>
and then execute that function in the Java code), the data about theState
and more importantlyContext
s is lost.Repro
Create a new project, with a file
polyglot/java/foo/foo/Foo.java
:then in
polyglot/java/foo
runjavac foo/Foo.java
to getpolyglot/java/foo/foo/Foo.class
.Now modify
src/Main.enso
to be:and run the project.
Expected results
Actual results
We can see that inside of the callbacks that were executed by a Java call both the State and output context are lost - the state is treated as uninitialized and the Output context gets 're-enabled'.
I don't think this is correct.