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

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-13 13:34:34

---------------------------
Vicente Juan Botet Escriba
----- Original Message ----- 
From: "Johan Torp" <johan.torp_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, May 13, 2008 11:42 AM
Subject: Re: [boost] Re view Request: future library : what does future of 
references exactly means?

>
>
> 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?

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();

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

You are right, the problem is not 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.

This is not more dangerous that
     Out& f();

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.

Vicente