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