This page is not created by, affiliated with, or supported by Slack Technologies, Inc.


Im not sure how a webworker backed agent or dosync makes any sense given the js environment


The bigger problem which you don't mention is how the heck are we going to share code with a worker thread


The activity of workers needs compile-time precoordination


Also js has no blocking calls, so send-off makes no sense


Maybe send makes sense for CPU-bound stuff, but having to message pass with a worker is a big overhead


And I never need stm in Jvm clojure so I'm not hankering for it in cljs. Again message passing chatter will dominate any possible benefit from parallelism


Better abstractions are those that target map-reduce/fork-join like workloads, or something actor like for a stateful process


There is a cljs lib out there that tries to address the former style of problem. Web worker actor-like API is not something I am aware of


Web workers should be treated more like sub processes rather than threads. Any API meant to address threading problems is going to be a bad fit imo, that includes agents and dosync


@favila Understood. Thanks for the input!


The code sharing works like in servant you have to be careful with it, but it works. Post-compile-time closures will probably cause the most trouble. I'm hoping to have a rough proof of concept up in the next few days.


and it may end up being the case that an agent abstraction isn't the right fit for (cl)js-land. I'm moreorless trying to spark some discussion and explore some solutions to multi-core computing with CLJS.


I was referring to send-off as a primarily io bound operation, or long running service. Perhaps a logging service. Perhaps you want to run 10 or 20 goloops with some services, but you don't want to clutter up the execution of your UI thread...


Whereas the send is mostly for lighting up all your cores at once, trying to get a job done as fast as possible.


The STM piece is pretty speculative, agreed. And most people probably won't be running atomic bank account transactions in the browser :wink:


and yeah, if your job is less than 25 milliseconds, you'll be spending most of your time in traffic.


@john I didn’t read the whole thread, but in future these Clojure’s primitives and STM could be implemented in ClojureScript using SharedArrayBuffer (shared memory) and Atomics (thread locks)


SharedArrayBuffer is too low-level (raw binary data), but there’s possibility that once it is implemented and used in every browser, we will get more APIs for shared memory (at least that’s what I heard from someone who is close to SharedArrayBuffer proposal)


@roman01la agreed. And I should be able to drop shared buffers in, once they're available. I'm already using Transferables to distribute ports out to the workers.


We may be able to win back some time using persistent data structures by only pushing the updated nodes to the underlying persistent tree structure over the wire.


For updates to a massive app-db in an SPA, that would be pretty important, if you want 10 workers updating your app-state.


Cool thing about that method: it wouldn't matter if you were talking to a worker over a local channel, over a websocket to a worker on a server, or to a worker in a peer. Not for minified code sharing, obviously - at least, not without a bunch of work up front - but just for distributed data objects, CLJS's persistent data structures can do some magic for us there.