Subject: Re: [boost] [fiber] Suggestions regarding asio
From: Nat Goodspeed (nat_at_[hidden])
Date: 2016-09-22 11:00:44
On Wed, Sep 21, 2016 at 3:50 AM, Tatsuyuki Ishi <ishitatsuyuki_at_[hidden]>
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