Re: [boost] Futures

Subject: Re: [boost] Futures
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2015-01-07 20:36:47

> Le 06/01/15 20:22, Vicente J. Botet Escriba a écrit :
> > Le 06/01/15 11:23, Niall Douglas a écrit :
> >> On 5 Jan 2015 at 22:41, Vicente J. Botet Escriba wrote:
> >>
> >>>> For example, right now can boost::wait_all() ever consume
> >>>> std::futures? I suspect not because the HANDLE on Windows or the
> >>>> futex on Linux is rather hard to get at.
> >>> The current implementation doesn't accept std::futures, but there is
> no
> >>> reason it can not accept other futures. All what is needed is the
> >>> Future::wait() interface.
> >>>
> >>> wait_for_any is different. The Boost thread implementation uses a list
> >>> of condition_variable to notify when a the future becomes ready.
> Having
> >>> a generic future<T>::notify_when_ready(condition_variable) will
> >>> surely help.
> >> I would *far* prefer a notify_when_ready(callable), not least because
> >> condition_variables are lost wakeup prone.
> > It is much easier to store a condition_variable than a Callable. In
> > addition it ensures that the future value provider will not block
> > until the callback finish and makes the user code thread safe, as the
> > code is executed on the thread of its choice.
> >> But then you're effectively making futures into ASIO async_result.
> >>
> >>
> > I'm not a fan of async_result, as the way the function is used depends
> > on a specific parameter. IMO, we need different functions when the
> > user must follows a different protocol.
> >
> 
> After some more thoughts, the callable interface is more open.
> 
> The condition_variable interface could be something like
> 
> // Return an unlocked LockableFutureHandle able to tell if the Future is
> ready once the lock has been locked.
> LockableFutureHandle Future::notify_when_ready(condition_variable&);
> 
> // pre-condition this is not locked
> void LockableFutureHandle::lock();
> 
> // pre-condition this is locked
> void LockableFutureHandle::unlock();
> 
> // pre-condition this is locked
> void LockableFutureHandle::is_ready();
> 
> This seems a little bit intrusive and is needed as the user need to
> check which future is ready.
> 
> Using a Callable (void()) like e.g.
> 
> template <class Callable>
> voidFuture::when_ready(Callable&&);
> 
> that doesn't consume the future, the user is able to store on the
> callable closure the mutex, the condition_variable and the index. When
> called it can store the index as the one that is ready and notify the
> condition variable.
> 
> An alternative could be to have some kind of lockable condition variable
> wrapping an index. The wait function could return the index.
> 
> voidFuture::notify_when_ready(LockableConditionVariable<std::size_t>&);
> 
> The user would call it as follows
> 
>    LockableConditionVariable<std::size_t> lcvi(i);
>    f.notify_when_ready(lcvi);
> 
> and will later call to wait to get the index.
> 
>    std::size_t index = lcvi.wait();

Whatever you do, I'd suggest not to tie the API to any of the kernel-based
synchronization objects.

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu