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

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-08 09:14:39

----- Original Message ----- 
From: "Anthony Williams" <anthony_w.geo_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, May 08, 2008 2:35 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: Tuesday, May 06, 2008 8:42 AM
>> Subject: Re: [boost] Review Request: future library (N2561/Williams 
>> version)
>>
>>
>>> "vicente.botet" <vicente.botet_at_[hidden]> writes:
>>>
>>>> why we don't need to protect get_future() function of multiple thread
>>>> access?
>>>
>>> By design you can only call this function once, so if multiple threads
>>> called
>>> it concurrently and that was safe, only one would get the future, and 
>>> the
>>> other would get an exception. The user should therefore use appropriate
>>> synchronization to ensure correct results anyway, so making this call
>>> thread-safe would not be of benefit.
>>>
>>
>> I don't understand the need of this function. Could you show a use case 
>> for
>> promise::get_future() function?
>
> promise::get_future() is the only way to get a future from a promise. 
> Since
> the whole point of using promise is to get the future, it's rather 
> pointless
> without it.

why this is not an internal feautre?

> Were you getting at something else?

Sorry, but I thouth that it is up to the promise to communicate with his 
future when the user do a set_value or set_exception or elsewhere

When the user will need the future of a promise?

Vicente