This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-05-12
Channels
- # announcements (4)
- # asami (3)
- # babashka (18)
- # babashka-sci-dev (2)
- # beginners (55)
- # calva (18)
- # clj-commons (23)
- # clj-kondo (2)
- # cljfx (7)
- # cljs-dev (15)
- # clojure (96)
- # clojure-europe (43)
- # clojure-losangeles (3)
- # clojure-nl (2)
- # clojure-uk (11)
- # clojurescript (1)
- # datalevin (2)
- # datomic (10)
- # events (1)
- # google-cloud (4)
- # gratitude (16)
- # helix (3)
- # hyperfiddle (63)
- # inf-clojure (13)
- # introduce-yourself (4)
- # ipfs (2)
- # jobs (2)
- # jobs-discuss (12)
- # leiningen (7)
- # lsp (15)
- # off-topic (38)
- # polylith (24)
- # portal (27)
- # remote-jobs (8)
- # sci (27)
- # spacemacs (5)
- # specter (1)
- # sql (5)
- # xtdb (41)
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.
@U0TU3SMNC is eval-string*
happening on the server side, JVM?
which it will call with the results, and I’m resetting an atom that’s defined in the closure
couldn't it be that your atom is being reset from different threads and that your function picks the wrong return value?