Re: [boost] Boost.Fiber review January 6-15

Subject: Re: [boost] Boost.Fiber review January 6-15
From: james (james_at_[hidden])
Date: 2014-01-11 13:20:51

On 11/01/2014 17:19, Nat Goodspeed wrote:
> In other words, the case in which you migrate fibers from one thread
> to another is not the only case in which fibers must be thread-safe.
> If you have even one additional thread (A and B), and some fiber AF on
> thread A makes a request of thread B that might later cause fiber AF
> to change state, all fiber state changes must be thread-safe.
I would think it almost certain that a real-world program will have more 
threads.

Given that a blocking system call is poisonous to throughput of all the 
fibres
on a thread (especially if a work stealing scheduler isn't running) then 
I would
expect most programs to delegate blocking calls to a 'real' thread pool and
use a future to deliver the result.

You need at least one thread-safe way to deliver data to a fibre, and I 
suspect
that in practice both 'enqueue message' and 'complete future' are needed
for convenience.  If you want just one thing, then the equivalent of a 
Haskell
MVar is probably the most effective.