Sorry for cross-posting.
Vicente J. Botet Escriba wrote:
I have a branch (https://github.com/boostorg/thread/tree/feature/non_blocking_futures) that don't blocks on any future, but this will break async.
FWIW, the design decision to let those (and only those) futures block on destruction which are returned from async was one of the really bad decisions made for C++11, however that's just my opinion (others agree, but yet others disagree). This flaw essentially caused us to spend many committee hours on discussions how to mitigate the situation, with proposed solutions ranging from 'leave it be as is' to as extreme as 'deprecate it now'. There seems to be a growing consensus however to develop other constructs which eventually could replace async, such as executors, etc. I'm a proponent of following that path. More generally, I strongly believe that we have to come up with a _coherent story_ for all kinds of (higher-level) parallelism in C++: task-based parallelism, asynchronous, continuation style programming, fork-join parallelism of heterogeneous tasks, simple fork-join (iteration based) parallelism, etc. All of this has to go hand in hand with a (orthogonal) vectorization story. We also need to think about integrating GPUs. The goal has to be to make parallelism in C++ independent of any external solutions such as OpenMP, OpenACC, etc. Many of the building blocks for this are already being discussed: executors and executor_traits for customizing the 'how and where' of task execution, executor parameters for grain-size control, and execution policies as the higher level facility allowing to tie everything together (see for instance HPX [7]). We (as a committee) already allow for passing execution policies as the first argument to parallel algorithms (Parallelism TS, N4505 [2]). We already have some facilities for task-based, asynchronous, and continuation style parallelism in place (Concurrency TS, N4501 [3]). We have a paper proposing task_blocks for fork-join parallelism of heterogeneous tasks (N4411 [4]). We have two competing (but converging) efforts for defining an executor concept (N4406 [5], PR0008R0 [6]). We have a (strong) proposal for simplifying continuation based programming (await, PR0057R0 [8]). We have attempts on integrating executors with existing facilities (Boost, HPX). We miss work on parallel ranges. We miss work on integrating data structures with data placement policies in conjunction with executors. We miss work on extending all of this to many-core, distributed, and high-performance computing. Etc. We (as a community) really need a higher level, over-arching approach which ties all of the above together! My plan is to work on a corresponding concept paper by the time of the committee meeting end of February 2016. Our group has outlined our current understanding and a possible approach to this here [1]. I'd like for this to be understood as a seed for a wider discussion. Needless to say, I'd very much like to collaborate on this with anybody interested in joining the effort. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu [1] http://stellar.cct.lsu.edu/pubs/executors_espm2_2015.pdf [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4505.pdf [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4501.html [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4411.pdf [5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4406.pdf [6] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0008r0.pdf [7] http://stellar-group.github.io/hpx/docs/html/hpx/manual/parallel.html [8] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0057r0.pdf