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

14 May 2008

      ----- Original Message ----- 
From: "Anthony Williams" <anthony_w.geo@yahoo.com>
To: <boost@lists.boost.org>
Sent: Wednesday, May 14, 2008 12:15 PM
Subject: Re: [boost] Review Request: future library (N2561/Williams version)
...
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
...
----- Original Message ----- 
From: "Anthony Williams" <anthony_w.geo@yahoo.com>
To: <boost@lists.boost.org>
Sent: Wednesday, May 14, 2008 10:55 AM
Subject: Re: [boost] Review Request: future library (N2561/Williams 
version)
...
"vicente.botet" <vicente.botet@wanadoo.fr> 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