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

Le 05/09/15 00:53, Giovanni Piero Deretta a écrit :

On Fri, Sep 4, 2015 at 7:54 PM, Oliver Kowalke wrote:

...

2015-09-04 20:10 GMT+02:00 Giovanni Piero Deretta :

...

- 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.

boost::fibers::future<> has to use internally boost::fibers::mutex instead of std::mutex/boost::mutex (utilizing for instance pthread_mutex) as boost.thread does. boost::fibers::mutex is based on atomics - it does not block the thread - instead the runing fiber is suspended and another fiber will be resumed. a possible future implementation - usable for boost.thread + boost.fiber - must offer to customize the mutex type. futures from boost.thread as well as boost.fiber are allocating futures, e.g. the share-state is allocated on the free-store. I planed to provide non-allocating future as suggested by Tony Van Eerd. Fortunately Niall has already implemented it (boost.spinlock/boost.monad) - no mutex is required. If boost.monad is accepted in boost I'll to integrate it in boost.fiber.

So, I do not want a non-allocating future, as I think it is actually counter-productive. I only want a way to combine boost::thread::future and boost::fiber::future (i.e. in a call to wait_all/wait_any). There are two ways to do that:

1) either a simple protocol that allows efficient future interoperation (note that efficient is key here, otherwise 'then' could also work) between distinct futures.

or

2) boost::fiber::future is simply a tiny wrapper over boost::thread::future that overrides the wait policy.

In the second case of course boost.thread must allow specifying a wait policy and must not use mutexes internally (it should either have a lock free implementation or use spin locks).

[...]

I've not a solution to this problem and as other I'm trying to find it. I don't think the solution to been able to work with different future with when_all/when_any come from making all of them deriving from a base class. We need a common interface/protocol for all of them of course, but we have yet to decide what is the type of then resulting future. While the subject is very important, I believe that it is out of the scope of the Fiber library review. Best, Vicente