Fork me on GitHub
#sci
<
2022-05-12
>
haywood19:05:23

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*?

haywood19:05:02

I’m getting odd behavior calling test-vars downstream, where a test-results atom created in the closure is ending up in another thread

haywood19:05:21

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.

haywood19:05:44

asking here is a last resort 😂

borkdude19:05:37

@U0TU3SMNC is eval-string* happening on the server side, JVM?

haywood19:05:05

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

borkdude19:05:52

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

borkdude19:05:32

What is test-vars, something from Clojure test?

haywood19:05:08

which is an odd duck admittedly

borkdude19:05:08

that may cause global side effects possibly

haywood19:05:28

so you can provide a clojure.test/report function

haywood19:05:54

which it will call with the results, and I’m resetting an atom that’s defined in the closure

haywood19:05:10

and the function eventually returns it

haywood19:05:28

it’s like the report call back when called is in the wrong thread

borkdude20:05:18

SCI by default does not run on any other thread

haywood20:05:42

yea it’s just local right?

haywood20:05:39

yea gotta be a clojure.test

borkdude20:05:12

couldn't it be that your atom is being reset from different threads and that your function picks the wrong return value?

borkdude20:05:40

> an atom that’s defined in the closure hm, that seems unlikely then

haywood20:05:35

(sci/new-var 'run-tests! #'extensions/run-tests!)

haywood20:05:12

that’s the function in question that creates the local atoms via let, and the new var is set on the namespaces map

haywood20:05:52

I’m gonna take a break from the problem for a few though 😞 thanks for your help

👍 1