From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-08 09:14:39
----- Original Message -----
From: "Anthony Williams" <anthony_w.geo_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
>>> "vicente.botet" <vicente.botet_at_[hidden]> writes:
>>>> why we don't need to protect get_future() function of multiple thread
>>> By design you can only call this function once, so if multiple threads
>>> it concurrently and that was safe, only one would get the future, and
>>> 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
>> promise::get_future() function?
> promise::get_future() is the only way to get a future from a promise.
> the whole point of using promise is to get the future, it's rather
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk