Issues with executor_t and when_all()

[aaronalbers]

I can't quite track this issue down but I think it has something to do with how we are forwarding and moving the supplied executor (I could be way off though).

#include <iostream>
#include <string>

#include <stlab/concurrency/default_executor.hpp>
#include <stlab/concurrency/future.hpp>
#include <stlab/concurrency/utility.hpp>


static stlab::executor_t make_executor(std::string n) {
   return [n](stlab::task<void()> f) mutable {
      std::cout << n << std::endl;
      stlab::default_executor(std::move(f));
   };
}

int main() {
   auto f = stlab::when_all(make_executor("executor"), [](auto x, auto y) { return x + y; }, 
        stlab::make_ready_future<int>(42, stlab::immediate_executor),
        stlab::make_ready_future<int>(42, stlab::immediate_executor));
   std::cout << "done:" << stlab::blocking_get(f) << std::endl;
   return 0;
}

Compiled with stlab folder in same directory as main.cpp:
clang++ main.cpp -std=c++14 -fcoroutines-ts -I.

Output:

executor
libc++abi.dylib: terminating with uncaught exception of type std::__1::bad_function_call: std::exception
Abort trap: 6

Expected:

executor
executor
done:84

[FelixPetriconi]

You are right the mistake is in future.hpp:1168, where the executor is moved into attach_when_args. I will fix this before the end of the week. Thanks for spotting!

[aaronalbers]

This still appears to be an issue in 1.3.3

[FelixPetriconi]

That's correct. I am still working on the fix. But other users needed urgently other fixes.
(The content of a release is described in the https://github.com/stlab/libraries/blob/develop/CHANGES.md)

[FelixPetriconi]

I am sure that I have a solution here. But currently, the Travis job with the clang thread sanitizer check fails while it passes locally for me with the same environment.

[FelixPetriconi]

Done in 1.4