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

Subject: Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-09-04 15:08:30

On 09/04/2015 08:34 PM, Nat Goodspeed wrote:
> 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.

Executors are mostly for spawning new stuff, which isn't that big of a 
problem. I think what you have in mind is execution context.

>
> Meanwhile -- Fiber requires its own set of synchronization primitives
> because only those primitives can permit other fibers to continue
> running on the same thread.
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>