Re: [boost] Review Request: future library (N2561/Williams version)

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-14 07:15:13

----- Original Message ----- 
From: "Anthony Williams" <anthony_w.geo_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, May 14, 2008 12:15 PM
Subject: Re: [boost] Review Request: future library (N2561/Williams version)

> "vicente.botet" <vicente.botet_at_[hidden]> writes:
>
>> ----- Original Message ----- 
>> From: "Anthony Williams" <anthony_w.geo_at_[hidden]>
>> To: <boost_at_[hidden]>
>> Sent: Wednesday, May 14, 2008 10:55 AM
>> Subject: Re: [boost] Review Request: future library (N2561/Williams 
>> version)
>>
>>
>>> "vicente.botet" <vicente.botet_at_[hidden]> writes:
>>>
>>>> Why you don't allow multiple callbacks? I suposse that this is related 
>>>> to
>>>> the implementation of do_callback
>>>>
>>>> void do_callback(boost::unique_lock<boost::mutex>& lock)
>>>> {
>>>>     if(callback && !done)
>>>>     {
>>>>         boost::function<void()> local_callback=callback;
>>>>         relocker relock(lock);
>>>>         local_callback();
>>>>     }
>>>> }
>>>>
>>>> You need to call all the callbacks with the mutex unlock, and you need 
>>>> to
>>>> protect from other concurrent set_wait_callback. So you will need to 
>>>> copy
>>>> the list of callbacks before unlock.
>>>>
>>>> Is this correct?
>>>
>>> That is correct with respect to the implementation,
>>
>> BTW, Braddock implementation do a move of the list of callbacks before 
>> doing
>> the callbacks. What do you thing about this approach?
>
> That's an interesting idea: rather than calling the callback every time 
> some
> thread waits on a future, it's only called on the first call. You could 
> make
> the callback clear itself when it was invoked if you want that behaviour, 
> as
> the promise or packaged_task is passed in to the callback.
>
>>> but I don't actually see
>>> the need for multiple callbacks. The callbacks are set as part of the
>>> promise
>>> or packaged_task. I can't imagine why that would require multiple
>>> callbacks. In any case, the user can provide that facility on their own 
>>> if
>>> required.
>>>
>>
>> What about the guarded schedule of Braddock?
>>     template future<T>
>>     schedule(boost::function<T (void)> const& fn, future<void> guard =
>> future<void>()) {
>>          promise<T> prom; // create promise
>>          future_wrapper<T> wrap(fn,prom);
>>          guard.add_callback(boost::bind(&JobQueue3::queueWrapped<T>, 
>> this,
>> wrap, prom));
>>          return future<T>(prom); // return a future created from the 
>> promise
>>     }
>>
>> Several task can be scheduled guarded by the same future.
>
> That's a completion callback, not a wait callback. My proposal doesn't 
> offer
> completion callbacks.
>

Why you don't want to provide completion callbacks? Have you another 
proposal for completion callbacks?

Maybe you could open the interface and return the last callback setting. 
This will result in a chain of responsabilities and the client must be aware 
of that with thow potential problems: growing stack and clients forgetting 
its responsabilities.

template<typename F,typename U>boost::function0<void>
boost::function0<void> set_wait_callback(F f,U* u)
{
    boost::function0<void> cb = callback
    callback=boost::bind(f,boost::ref(*u));
    return cb;
}

In this case it is also  needed to reset the callback, other wise the
void do_callback(boost::unique_lock<boost::mutex>& lock)
{
    if(callback && !done)
    {
        boost::function<void()> local_callback=callback;
        callback.clear();
        relocker relock(lock);
        local_callback();
    }
}

Vicente