I think this is mostly the domain of https://github.com/leonoel/missionary/blob/master/src/missionary/impl/Reactor.cljs but the lingo isn't something I'm familiar with yet

> are there any docs on how missionary schedules work to be done? Still mostly in my head, but the main rule is : the work is done when it can be done, by the thread that made the work doable > how the differences between CLJS and CLJ are managed There shouldn't be any difference in practice, cljs is a special case of clj > I think this is mostly the domain of https://github.com/leonoel/missionary/blob/master/src/missionary/impl/Reactor.cljs This text block describes the implementation of stream! and signal! only LMK if you have more specific questions

sure, let me throw out a few questions at top of mind: when an event is received (e.g. a watch sees a new value in an atom), when and where does calculation of the flow graph begin? immediately, or is it queued? when calculating a graph of flows, does it park/pause the calculation or run the entire graph until stabilization synchronously? is the work split up across "process" boundaries? I'm still working on the lingo to know exactly what creates a new process.

it's a bit hard for me to untangle the "where" since CLJS has a single thread, whereas I'm guessing you take advantage of multiple threads on the JVM 😄

> when an event is received (e.g. a watch sees a new value in an atom), when and where does calculation of the flow graph begin? immediately, or is it queued? immediately > when calculating a graph of flows, does it park/pause the calculation or run the entire graph until stabilization synchronously? propagation though the graph happens synchronously, stabilization is reached when no more flows are ready to transfer > is the work split up across "process" boundaries? not sure to understand the question > what creates a new process it depends on the operator. some of them just build a static pipeline stage on boot (e.g latest), some are more dynamic and can spawn multiple child processes over their lifecycle (e.g ap) > I'm guessing you take advantage of multiple threads on the JVM Apart from the sleep scheduler, there's no hidden thread. If you want multithreading, you have to be explicit about it, and specify the threadpool with via. cpu and blk are provided for convenience but they're not mandatory and not used internally.

thanks, that answers a lot! > > is the work split up across "process" boundaries? > not sure to understand the question I was thinking about how core.async go blocks will park the computation on the thread it's running on at channel boundaries, so you can effectively time slice a computation by using e.g. a go-loop . it sounds like missionary doesn't make that kind of scheduling choice for you

exactly

other than sleep, is there a way of handling asynchrony within a flow? e.g. if I have some async I/O I want to await on to produce the next value

sure, ap/`?` works with any task