Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13

Subject: Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13
From: Nat Goodspeed (nat_at_[hidden])
Date: 2015-09-04 14:34:06

On Fri, Sep 4, 2015 at 2:10 PM, Giovanni Piero Deretta
<gpderetta_at_[hidden]> wrote:

> - Boost.Fiber is yet another library that comes with its own future
> type. For the sake of interoperability, the author should really
> contribute changes to boost.thread so that its futures can be re-used.
>
> - In theory Boost.Thread any_condition should be usable out of the box.
>
> This probably should lead to a boost wide discussion. There are a few
> boost (or proposed) libraries abstract hardware and OS capabilities,
> for example boost.thread, boost.asio, boost.filesystem,
> boost.iostream, boost.interproces (which also comes with its own
> mutexes and condition variables) and of course the proposed afio and
> fiber. At the moment they mostly live in separated, isolated worlds.
> It would be nice if the authors were to sit down and work out a shared
> design. Or more practically at least added some cross library
> interoperability facilities. This is C++, generalization should be
> possible, easy and cheap.

The problem is this: what does it mean to "suspend"? There is no
existing facility that can suspend exactly the calling fiber -- which
means passing control to the fiber manager, leaving the current thread
running to resume another fiber.

You're right: if we had a pluggable notion of a suspend operation, we
could reuse all Boost.Thread synchronization primitives -- as well as
normal "blocking" I/O functions. I would like to see that happen. But
it requires that all such libraries be reimplemented in terms of the
pluggable suspend.

I have a vague notion that this concept is tied to the use of
executors, which are themselves a work in progress.

Meanwhile -- Fiber requires its own set of synchronization primitives
because only those primitives can permit other fibers to continue
running on the same thread.