On Wed, Sep 21, 2016 at 3:50 AM, Tatsuyuki Ishi wrote: The current example seems non-flexible and very hacky.

1. The timer handler has no problem, since it's expected to be called from any thread. (Description in "Deeper Dive into asio" is meaningless) 2. Possible alternatives: * A post(empty lambda) is a little bit waste but solves the threading problem. It wakes up one thread by doing interrupt of epoll etc. Maybe adding a interrupt method to asio codebase could be more efficient. * One thread doing event polling and the other doing condvar is enough. Since we're not expecting a slow handler (most times, it just make a fiber ready), this should be sufficient. Correct me if I'm wrong.

I appreciate your interest! But I am embarrassed to admit that I do not yet understand your specific suggestions. When considering using multiple threads with an io_service passed to a custom Boost.Fiber scheduler, I keep bumping into the problem that a given fiber scheduler instance must always run on its original thread -- but I know of no way to give an Asio handler "thread affinity." How do we get processor cycles to the scheduler on the thread whose fibers it is managing? I would be very interested to look over your custom scheduler implementation, though!