John Maddock wrote:
With apologies for coming to the discussion late, it seems to me that many future implementations including the ones under discussion are high level interfaces that are "feature rich". Nothing wrong with that, it's exactly what a lot of folks need.
But I would also be interested in a super-lightweight future used for more low-level task-based parrallelism.
My hope is that we can standardize some basic future in step 1 and lots of libraries/features building on it in step 2. I have also been concerned that future is not as light weight as I'd hope'd it be. John Maddock wrote:
In my dreams <g>, it would be something like:
* Create a scoped object that executes the "future" in parrallel, constructing the object would be no more expensive than a trivial function call - so no memory allocation or mutexes allowed, only lock-free programming. * The future would be executed using a thread drawn from a pool - or possibly a local team - so there's no thread creation overhead either (except at program startup, or possibly the first time a future is invoked). * At a later point in the same scope, join with the future, again this should be a "trivial" lock-free operation if the future has completed.
You seem to be thinking of the future as unfinished work. It might also be a pending response to an out-of-process asynchronous request or something else. John Maddock wrote:
So... is such a beast possible? Or are threads actually too heavyweight for such usage?
I don't know. I haven't been think about lock-less programming at all, but I will keep it in mind. 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.