thread support

[klemens-morgenstern]

The library is currently strictly single threaded, and the former async::thread class has been removed. If we want multi-threading we need would need synchronization primitives, such as mutex etc. (the sam stuff, but simpler).

Potentially also thread-safe channels.

[ned14]

Surely the bare minimum viable support needed here is to reparent something from one executor to another? You can build anything else you want on top of that.

[jsaf0]

Simple synchronization primitives like Event and Lock from Python’s asyncio (https://docs.python.org/3/library/asyncio-sync.html) would still be very convenient to have as part of this library - also in a single-threaded context.

[klemens-morgenstern]

This was the thread type (that can be restored): a7fe353

boost::async::thread thr()
{
  boost::asio::steady_timer tim{co_await boost::asio::this_coro::executor, std::chrono::milliseconds(100)};

  auto exec = co_await boost::asio::this_coro::executor;
  co_await tim.async_wait(boost::asio::deferred);
}

boost::async::main co_main(int argc, char ** argv)
{

   co_await thr();
   co_return 0;
}

[klemens-morgenstern]

Actually all we need in addition is to be able to safely have co_await cross executors:

boost::async::thread thr(async::channel<int> foreign_channel) // < different executor
{
  co_await thread_safe(foreign_channel.read()); // has an associated executor
  co_await thread_safe(foreign_channel.get_executor(), foreign_channel.read());
}

[klemens-morgenstern]

Alternatively we could have a coro that is attached to a thread but can be awaited safely, like this:

thread::safe coro(thread & thread_to_run_on)
{
  // everything in here runs on `thread_to_run_on`
   co_await 
}

[klemens-morgenstern]

await_on doesn't work with select.

latch might do:

boost::async::thread thr(latch<int> l)
{
  l.notify(42);
}

boost::async::main co_main(int argc, char ** argv)
{
   latch<int> l;
   thread(l).detach();

   co_return co_await l;
}

Alternatively, sam could be ported. Unlike raw sam we can actually detect if we're recursive based onte thread_local and/or coroutine's own executor. Thus you won't accidentally dead-lock.

[klemens-morgenstern]

@madmongo1

[klemens-morgenstern]

Added an spsc-queue example, we don't need this with unique_handle and the other stuff being in the code.

[pfeatherstone]

I'm struggling to see why threading has become an issue here, and why we would need synchronization primitives. I'm not an expert like you guys, so that's likely why... However, in Asio, you can use awaitable or coro in a multi-threaded environment safely, provided you carefully choose your executors, e.g. implicit/explicit strands, or channels. Moreover, users can "bring their own threads" by simply calling asio::io_context::run on multiple threads. You don't have to use special threads. I feel like this is causing more confusion to asio users. Maybe cppalliance's book on asio, concurrency and coroutines is much needed. What were @chriskohlhoff 's comments on this library? Thank you everyone for the fantastic work!