Re: [boost] future .vs. Join, is "future" a form of message passing?

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-16 05:01:11

I think of futures as a form of message passing. The message can only be sent
once by the promise and the associated futures are listeners which buffer
the result. In the unique_future case, we limit ourselves to one listener.
But this is only because I'm well familiar with message passing.

I'm sure you can build futures on top of join, but the library is very
important in it's own case and I think it's important it doesn't have too
many dependencies.

yigong liu-2 wrote:
> 
> This code presents a very interesting idiom: we first create future
> (inside
> promise<T>'s constructor) - the message channel. Then we bundle the work
> item up with prom - the sending-interface of channel together, and pass
> this
> bundle to worker thread. (Asynchronously the worker thread will do the
> work
> and write the result to the sending-interface of channel). 
> 

I'm really sceptical about this. It might seem natural when the
promise-fulfilling thread is a worker thread but in general I think it's
very dangerous. Basically a promise-fulfilling thread should not execute
code that belongs to listener threads - what should we do if an exception is
thrown? The promise-fulfilling code can't be ready for that and handle it
and the listening thread doesn't get notified. Also, the listener thread do
not need to make their code threadsafe if they know they are the ones
executing it.

I've been thinking about how you can bundle "work" with a future but so that
it's get executed in the future-listening thread. See
http://www.nabble.com/-future--Early-draft-of-wait-for-multiple-futures-interface-to17242880.html
for an alpha alpha version of the interfaces.

yigong liu-2 wrote:
> 
> If we can wrap around our mind and think of "future" as a form of message
> passing, we can gain much freedom from traditional concept of "future",
> for
> example:
> 

This freedom also means a more complex model and a steeper learning curve. I
think futures is a nice and simple concept in it's own right and that there
is a value in hiding away how it's implemented.

If join calculus or some other message passing library was C++-standardized
and well understood by most users we might have wanted to implement futures
on top of it.

My five cents.

Btw, this was a very good example which shows the power of join. Think about
adding it to the documentation. 

Johan
-- 
View this message in context: http://www.nabble.com/future-.vs.-Join%2C-is-%22future%22-a-form-of-message-passing--tp17269380p17270415.html
Sent from the Boost - Dev mailing list archive at Nabble.com.