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 17:51:53

vicente.botet wrote:
> 
>>> 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?
> 
> What do you propose instead? What do you think of
>      future<Result> f(cosnt InOut& in, future<InOut>& out);
> 
>     future<InOut> fv;
>     r= f(v,  fv)
>     v = fv.get();
> 

If result was binary - succeed or "not possible" I would use 
  unique_future<boost::optional<InOut> > f();
otherwise
  unique_future<tuple<Result, InOut> > f();
or
  unique_future<variant<ErrorCode, InOut> >

I'm assuming InOut is movable and we have r-value references. Otherwise, use
unique_ptr/auto_ptr instead of InOut. If we need shared_futures I would use
shared_ptr instead of InOut. 

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.
> 
> This is not more dangerous that
>      Out& f();
> 

Sharing references between threads is always very dangerous and should be
avoided. The owning thread can typically not know when the other thread will
access it and must hence keep it alive until the program terminates and can
never alter the data again (unless it's a concurrent object). 

vicente.botet wrote:
> 
> We know how dangerous it is and we use every time. This reference point 
> usualy to a member object, and the object can be deleted.
> 

The single threaded case is a lot less dangerous. 

As a side note, I think return-by-reference is an almost deprecated
programming style. Code which depend on boost can use auto_ptr, shared_ptr,
variant, optional and tuples to easily return data, unless performance is
_really_ critical. R-value references will remove the expensive copying for
movable types too. 

Those are my thoughts on the matter.

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