A TSEventThread API makes sense to me; maybe Kees has something similar in the implementation for XXXOnThread() he mentioned. Regardless, it sounds like this would allow fine-grained control of where code associated to a continuation is executed, which would be great as far as I am concerned.
Otto On Thu, Aug 16, 2018 at 12:19 AM Alan Carroll <solidwallofc...@oath.com.invalid> wrote: > In the core, when a continuation is scheduled on a specific thread that is > not the current thread, it's because there is a locked object with the lock > held on another thread, and the goal is to have the continuation run on > that thread. This can help gather interacting objects on the same thread > where they won't have lock contention (because if I try to get a mutex > that's locked on *this* thread, it is successful). >
