I absolutely agree. "future islands" are a big problem which need a solution very soon. To some extent the shared state as described in the standard could be the interface to be used by the different islands. What we miss here is a properly defined interface etc.. I probably didn't make that clear enough in my initial mail, but i think this unifying future interface should be the way forward so that different domains can use this to implement their islands. FWIW, we already have that in HPX and we are currently integrating OpenCL events within our "future island", this works exceptionally well.
I personally think that any notion of any shared state in futures is one of the big design mistakes. Instead of "future as a shared_ptr", think "future as a pipe".
A future is no 'pipe', it's just the receiving end of a pipe which can be used once.
I missed that. Can you link the source/documentation/proposal once more please?
Try http://comments.gmane.org/gmane.comp.lib.boost.devel/255022. The key insight of that proposal is the notion of static composition of continuations as the core design. One then composes, at compile-time, a sequence of continuations which implement any combination and variety of future you like, including the STL ones and the proposed Concurrency TS ones. You will note how the functional static continuations are effectively monadic, and therefore these elementary future promises are actually a library based awaitable resumable monadic toolkit which could be used to write coroutine based Hana or Expected monadic sequences which can be arbitrarily paused, resumed, or transported across threads.
The power of the proposed model lies in dynamic composition of asynchronous operations, not static composition. Do I misunderstand something? Static composition could help for things like NT2, though.
Universal composure of any kind of future with any other kind is possible when they share the same underlying kernel wait object. I intend to use my proposed pthreads permit object which is a portable userspace pthreads event object as that universal kernel wait object. If widely adopted, it may persuade the AWG to admit permit objects into POSIX threads for standardisation, that way C and C++ code can all use interoperable wait composure.
That's exactly the issue! You will not be able to make all synchronization use the same kernel objects. HPX uses its own non-kernel objects for that, for instance. Using kernel objects makes things slow. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu