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

Subject: Re: [boost] Futures (was: Re: [compute] Some remarks)
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-01-05 06:49:31

On Monday, January 05, 2015 11:01:53 Niall Douglas wrote:
> On 4 Jan 2015 at 9:52, Hartmut Kaiser wrote:
> > > 1. They tie your code into "future islands" which are fundamentally
> > > incommensurate with all code which doesn't use the same future as
> > > your code. Try mixing code using boost::future and std::future for
> > > example, it's a nightmare of too easy to be racy and unmaintainable
> > > mess code. If Compute provided a boost::compute::future, it would yet
> > > another new future island, and I'm not sure that's wise design.
> > 
> > The easiest way to deal with this is to introduce a Future concept and
> > implement everything in terms of it. A solid set of traits/concepts-lite
> > should cover that.
> 
> I don't think it's that easy because really it comes down to
> commonality of kernel wait object, or rather, whether one has access
> to the true underlying kernel wait object or not.

You make the assumption that you only ever synchronize on kernel space 
objects. This is not at all required nor necessary.

> 
> For example, right now can boost::wait_all() ever consume
> std::futures? I suspect not because the HANDLE on Windows or the
> futex on Linux is rather hard to get at.

In which scenario do you have both a Windows HANDLE and a Linux futex?

<snip>
 
> > > Replacing the entire concurrency engine and indeed paradigm in your
> > > C++ runtime is, I suspect, too scary for most, even if the code
> > > changes are straightforward. It'll be the "bigness" of the concept
> > > which scares them off.
> > 
> > What if the whole std library was based on something like HPX? In this
> > case
> > the user wouldn't have to care about this anymore, right?
> 
> That works for me. I just don't want yet another STL implementation
> to support.

Luckily, you don't have to. In the case of HPX, we'd only need to replace a 
particular subsystem of say libc++.

> 
> > > To that end, the non-allocating basic_future toolkit I proposed on
> > > this list before Christmas I think has the best chance of "fixing"
> > > futures. Each programmer can roll their own future type, with
> > > optional amounts of interoperability and composure with other future
> > > islands. Then a future type lightweight enough for a SHA round is
> > > possible, as is some big thick future type providing STL future
> > > semantics or composure with many other custom future types. One also
> > > gains most of the (static) benefits of ASIO's async_result, but one
> > > still has ABI stability.
> > 
> > Non-allocating futures are a step in the right direction. But even those
> > require to solve some of the problems you mentioned. Otherwise they will
> > make the issue of having future-islands just a bit bigger...
> 
> Eliminating future islands is, I suspect, not something the C++
> community can entirely do alone. We are, as a minimum, going to have
> to petition POSIX for improved runtime support. We probably ought to
> have our ducks in a row before that though.

Again the assumption that you need kernel based synchronization which does not 
hold.

> 
> Niall