Thomas Heller

I am not convinced. While the suggested solutions work and are indeed somewhat elegant. They do not need to call the parallel algorithms in the first place. Calling std::for_each instead...

I think our problems are two fold. We need solutions being developed from top-down (the algorithm point of view) and bottom-up (optimization in the scheduling). They can progress more or...

Am 12.05.2014 16:57 schrieb "Agustín Bergé" [email protected]: > We have a number of different utilities that wait on futures. Each > implements their own callbacks to wait on future completion....

While thinking about this, I am getting more and more to the conclusion that async, dataflow, invoke_when_ready and apply should be merged alltogether into async and apply. This won't break...

Am 21.11.2017 10:46 vorm. schrieb "Mikael Simberg" : @sithhell - For --hpx:attach-debugger, I suppose you'd want something more than the help text that is printed at startup/exception by hpx? Yes,...

the most consistent and, IMHO, leanest way to accomplish this is via an executor. On the executor side of things, you can block until all tasks are completed, the implementation...

Moving to 1.0.0 since it is not critical for the next release.

@khuck can you try a build with address sanitizer? This is usually very accurate in pinpointing to issues

@khuck for the linker errors, configure your HPX build with `-DHPX_WITH_SANITIZERS=On`. This should solve most of them.

@stevenrbrandt the stack switching is perfectly fine with asan, there are no false positives there. The errors you are seeing are genuine bugs on our side. If they are severe...