are there any parallel/threading subtleties for a request handler on the server that creates a new context and executes some code using eval-string*?
I’m getting odd behavior calling test-vars downstream, where a test-results atom created in the closure is ending up in another thread
so if you run the same operation in two different browsers, you can see the test results in the other, they collide somehow but I’m not sure. the threads they start in are different.
asking here is a last resort 😂
@haywood is eval-string* happening on the server side, JVM?
yea
I wasn’t forking the context from the ‘factory’ function, which I’m trying now
Does your eval-string use :load-fn as well?
nop
What is test-vars, something from Clojure test?
yea
which is an odd duck admittedly
that may cause global side effects possibly
so you can provide a clojure.test/report function
which it will call with the results, and I’m resetting an atom that’s defined in the closure
and the function eventually returns it
it’s like the report call back when called is in the wrong thread
SCI by default does not run on any other thread
yea it’s just local right?
indeed.
gotcha
yea gotta be a clojure.test
couldn't it be that your atom is being reset from different threads and that your function picks the wrong return value?
> an atom that’s defined in the closure hm, that seems unlikely then
(sci/new-var 'run-tests! #'extensions/run-tests!)
that’s the function in question that creates the local atoms via let, and the new var is set on the namespaces map
I’m gonna take a break from the problem for a few though 😞 thanks for your help