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
Given that a blocking system call is poisonous to throughput of all the
on a thread (especially if a work stealing scheduler isn't running) then
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
that in practice both 'enqueue message' and 'complete future' are needed
for convenience. If you want just one thing, then the equivalent of a
MVar is probably the most effective.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk