Re: [boost] Futures (was: Re: [compute] Some remarks)

Subject: Re: [boost] Futures (was: Re: [compute] Some remarks)
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2015-01-05 08:39:58

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