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

Subject: Re: [boost] Boost.Fiber review January 6-15
From: Nat Goodspeed (nat_at_[hidden])
Date: 2014-01-11 12:19:29

On Fri, Jan 10, 2014 at 2:50 AM, Antony Polukhin <antoshkka_at_[hidden]> wrote:

> Back to the fiber_base. There's too many atomics and locks in it. As I
> understand, the default use-case does not include thread migrations so
> there is no need to put all the synchronizations inside the fiber_base.
> round_robin_ws and mutexes work with multithreading, ideologically it's the
> more correct place for synchronizations. Let fiber_base be thread unsafe,
> and schedulers and mutexes take care about the serializing access to the
> fiber_base. Otherwise singlethreaded users will loose performance.

Niall Douglas said:

> I definitely need the ability to signal a fibre future belonging to thread A
> from some arbitrary thread B.

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.

An application running many fibers on exactly one thread (the
process's original thread) is an interesting case, and one worth
optimizing. But I'm not sure how the library could safely know that.
If you depend on the coder to set a library parameter, some other
coder will later come along and add a new thread without even knowing
about the fiber library initialization. If there were some way for the
library to count the threads in the process, a new thread might be
launched just after the fiber library has made its decision.

Either way, the complaint would be: "This library is too buggy to use!"

Better to be thread-safe by default.