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
On 11/01/2014 17:19, Nat Goodspeed wrote: 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.