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-inte... 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-... Sent from the Boost - Dev mailing list archive at Nabble.com.