Re: [boost] Re view Request: future library : what does future of references exactly means?

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-13 05:42:45

vicente.botet wrote:
> 
> Imagine now we had a function which returs a value and had an out
> parameter 
> (maybe by reference)
> 
> Result f(InOut& ref);
> 
> Now we want to refactor this function (either because the new
> implementation 
> will introduce an IO wait, or because the old blocking  implementation
> could 
> not be supported. Which should be the interface of the new function. The 
> first thing could be to try with
> 
>     future<Result> f(InOut& ref);
> 
> but nothing forbids the caller to use the ref parameter before the
> operation 
> has completed and which could be invalid. If we want consistency what we 
> would need is something like
> 
>     future<Result> f(future<InOut&>& ref);
> 

Firstly, this is a dangerous design. The calling thread must keep the
reference alive until the future is ready - no matter what. For instance,
what if it's owner thread tells it to terminate? 

Secondly, you can't prohibit the calling thread to access it's original
reference. So the problem isn't really solved.

Presently, I haven't seen any use cases which would motivate reference
support for futures. Not allowing references is a safety net in it's own
right.

vicente.botet wrote:
> 
> Yet another example
>     future<Out&> f();
> 

This is also very dangerous, the promise-fulfilling thread must guarantee
that the reference is valid until program termination as it can't detect
when the future dies. Even if it could detect future destruction, it would
be a strange design. Shared_ptrs or some kind of moving should be applied
here.

Johan

-- 
View this message in context: http://www.nabble.com/Review-Request%3A-future-library-%28Gaskill-version%29-tp16600402p17204773.html
Sent from the Boost - Dev mailing list archive at Nabble.com.