[cpp-threads] Re: Thread API interface tweaks

[Peter Dimov]

Ion Gaztañaga wrote:
>> Peter's design adds an extra start-function wrapper around even what
>> thread sees, necessitating a different launcher.  That appears key to
>> having futures be non-intrusive.
>
> This sounds familiar to me ;-) Essentially, Peter has designed the
> same implementation of my Kevlin's N1883 approach. I, like Peter,
> implemented future (joiner, in my/Kevlin's library) as a shared_ptr of
> an implementation class. In that paper I proposed standardizing the
> implementation, so that everyone could create it's own factories
> ("threaders" in my library). [...]


> With a future that delegates the implementation to another class via
> virtual functions we can design a library that returns a future using
> a thread for each operation (imagine a network dns operation). In the
> next version we can use thread-pools or operating system's own
> asynchronous network operations but we still return the same future.

Ion, thanks for joining the discussion. :-)

Maybe you should take a second look at my proposed future<>, though. The 
implementation class is not exposed/standardized and there are no virtual 
functions, but everyone can still create his own factories/executors and it 
is possible to use a future<> to return an arbitrary asynchronous result.

A future<> is essentially a single element container. The executor passes 
the future to the "producer" and returns a copy of the same future to the 
consumer. The produces places the result into the future<> when ready; the 
consumer inspects the future<> or blocks until a result is available.

The low-level thread knows nothing about futures and does not track them in 
any way.

I gave three examples of executors as proof that it is possible to write 
them in "user space" above the supplied future/task/thread primitives.