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

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

----- Original Message ----- 
From: "Anthony Williams" <anthony_w.geo_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, May 11, 2008 11:53 AM
Subject: Re: [boost] Review Request: future library (N2561/Williams version)

> * Finally, I've added a set_wait_callback() function to both promise and
>  packaged_task. This allows for lazy-futures which don't actually run the
>  operation to generate the value until the value is needed: no threading
>  required. It also allows for a thread pool to do task stealing if a pool
>  thread waits for a task that's not started yet. The callbacks must be
>  thread-safe as they are potentially called from many waiting threads
>  simultaneously. At the moment, I've specified the callbacks as taking a
>  non-const reference to the promise or packaged_task for which they are 
> set,
>  but I'm open to just making them be any callable function, and leaving it 
> up
>  to the user to call bind() to do that.

Hi,

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?

Anyway, IMO, having a single call back could motivate a user wrapper which 
offer "bugy" multiple callbacks.

Vicente