Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13
On Fri, Sep 4, 2015 at 2:10 PM, Giovanni Piero Deretta <gpderetta@gmail.com> 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.
On 09/04/2015 08:34 PM, Nat Goodspeed wrote:
On Fri, Sep 4, 2015 at 2:10 PM, Giovanni Piero Deretta <gpderetta@gmail.com> 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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Nat Goodspeed -
Thomas Heller