sci 2022-05-12

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?

I wasn’t forking the context from the ‘factory’ function, which I’m trying now

Does your eval-string use :load-fn as well?

What is test-vars, something from Clojure test?

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?

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

👍 1