How to process user callbacks in parallel while guaranteeing ordering? about caproto

[tacaswell]

A custom thread pool with a non-trivial 'affinity' policy? Would require pushing a lot of information down into the control layer though...

To some degree this is probably something the application should take care of and only register light-weight "move it from your queue to mine" operations directly on the PVs. We could ex, give each top-level ophyd object it's own thread (or group them somehow) so sleeps won't mess with other devices?

[danielballan]

That seems right. I liked the idea of "I'll just put in a lock inside my callback," until we realized that order wasn't guaranteed even so. "Move it from your queue to mine," is a better version of that. Group by Devices to keep their components from getting too far out of sync is sensible.

[danielballan]

New thought on this: a server only guarantees time ordering per circuit, so it is safe to move from one worker thread per context to one worker thread per circuit.

I think we should extend the same approach we have now: give users one thread pool per circuit but put one worker in the pool by default. Leave it up to them whether to turn up the number of workers to get more concurrency in some use case where it is OK to start one job before the previous job has completed.

[danielballan]

The idea in my previous comment was implemented some time ago in #320. I think this is the best we can do without adding a bunch of complexity ("a non-trivial affinity policy"). I'm going to close -- feel free to reopen if you thing it's worth going further here.