Subject: Re: [boost] Boost.Fiber mini-review September 4-13
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-09-05 19:37:43
Le 05/09/15 00:53, Giovanni Piero Deretta a écrit :
> On Fri, Sep 4, 2015 at 7:54 PM, Oliver Kowalke <oliver.kowalke_at_[hidden]> wrote:
>> 2015-09-04 20:10 GMT+02:00 Giovanni Piero Deretta <gpderetta_at_[hidden]>:
>>
>>> - 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