Avoid async scope lockup

[maxbachmann]

exec::task<void> test(asio::io_context &ioContext)
{
    asio::steady_timer timer(ioContext);
    timer.expires_after(std::chrono::seconds(10));
    auto [error] = co_await timer.async_wait(asio::as_tuple(exec::asio::use_sender));
}

exec::task<void> test2(exec::async_scope& scope, asio::io_context &ioContext)
{
#if 1
    co_await exec::reschedule_coroutine_on(stdexec::inline_scheduler{});
    co_await scope.nest(test(ioContext));
#elif 0
    co_await stdexec::on(stdexec::inline_scheduler{}, scope.nest(test(ioContext)));
#elif 0
    co_await scope.nest(stdexec::on(stdexec::inline_scheduler{}, test(ioContext)));
#endif
}

exec::task<void> test3(exec::async_scope& scope, asio::io_context &ioContext)
{
    co_await test2(scope, ioContext);
}

    asio::io_context ioContext;
    MyThread recvThread;
    std::optional<exec::async_scope> asyncScope;
    asyncScope.emplace();
    exec::static_thread_pool ctx{1};

    asio::executor_work_guard<asio::io_context::executor_type> workGuard(
        asio::make_work_guard(ioContext));

    recvThread.start([&]
        {
            ioContext.run();
            printf("test\n");
        }, "client_network_thread");


    exec::start_detached(stdexec::starts_on(MainThreadScheduler(), test3(*asyncScope, ioContext)));
    Scheduler::getSingleton()->run(GetTicks());

    sleep(5);
    workGuard.reset();

    asyncScope->request_stop();
    recvThread.join();
    asyncScope.emplace();

What I am attempting to do is to wrap an async function in an async scope t make it cancellable.
In this example the MainThreadScheduler only schedules one initial time so it is expected that it will never fully finish the test3 task.

However I would still like to successfully cancel it. In the test2 function the first case works as expected. Both case 2 and 3 assert inside the asyncScope destructor since the work isn't considered finished. It wasn't fully clear to me why the work isn't considered finished in these cases. Especially in case 2.

[maxbachmann]

With the standard counting_scope implementation:

    co_await exec::reschedule_coroutine_on(stdexec::inline_scheduler{});
    co_await stdexec::associate(test(ioContext), scope.get_token());

the first case also has the same problem.

Is this something supposed to be solved in a different way? I was using this e.g. when I have a class with a shutdown function that has to cancel all async work performed inside async member functions.

[maxbachmann]

I did also attempt to use spawn_future instead but again this somehow only works with async_scope but not with counting_scope:

    co_await stdexec::spawn_future(
        test(ioContext),
        scope.get_token(),
        stdexec::prop(stdexec::get_scheduler, stdexec::inline_scheduler{})
    );

still fails, while

    co_await scope.spawn_future(
        test(ioContext),
        stdexec::prop(stdexec::get_scheduler, stdexec::inline_scheduler{})
    );

succeeds

[maxbachmann]

@ispeters @ericniebler pinging you two since you worked on the corresponding pr for the standard counting_scope (#1713)

[ispeters]

Hi @maxbachmann, I don't think I really understand your scenario so I have a bunch of questions.

What I am attempting to do is to wrap an async function in an async scope t[o] make it cancellable.

Can you elaborate? If I interpret you literally, I think what you mean is that you want to "add cancellability to an uncancellable async function" by associating it with a scope, which isn't possible.

co_await timer.async_wait(asio::as_tuple(exec::asio::use_sender));

I'm not familiar with ASIO or its integration with stdexec—is that async_wait expected to respond to stop requests? If not, it won't be cancellable.

In this example the MainThreadScheduler only schedules one initial time so it is expected that it will never fully finish the test3 task.

However I would still like to successfully cancel it.

A cancelled async function still completes, it just completes with set_stopped instead of either set_value or set_error so, again, interpreting you literally, it's a problem if test3 never completes—it must complete with set_stopped for it to be considered "cancelled" rather than "still running".

Both case 2 and 3 assert inside the asyncScope destructor since the work isn't considered finished. It wasn't fully clear to me why the work isn't considered finished in these cases.

I'm not sure what the non-standard scope's behaviour is, but std::execution::counting_scope (and simple_counting_scope) both require that you join the scope before destroying it if any work is ever associated with it—it's irrelevant whether the work is "finished", you must await the join-sender returned from scope.join(). See [exec.simple.counting.ctor] paragraph 2 and [exec.simple.counting.mem] paragraphs 7 to 9 for the details.

[maxbachmann]

Can you elaborate? If I interpret you literally, I think what you mean is that you want to "add cancellability to an uncancellable async function" by associating it with a scope, which isn't possible.

I do have cancellable functions and just intend to add an extra cancellation trigger for things like shutdown handling. So in pseudo code:

class MyClass:
    asyncScope

   void shutdown():
        asyncScope.cancel()
        asyncScope.join()

   async void func():
      co_await asyncScope.nest(funcImpl)

In this specific case the MainThreadScheduler only schedules the coroutine to the main thread and func could be started on it. Now it's relevant that when cancelling the asyncScope it doesn't have to schedule back to the original scheduler during the shutdown since this would deadlock.

it's irrelevant whether the work is "finished", you must await the join-sender returned from scope.join()

Ah I didn't know about this and this brings the behaviour of the standard and async scope in line with each other.
Now similar to asyncScope nesting via:

    co_await exec::reschedule_coroutine_on(stdexec::inline_scheduler{});
    co_await stdexec::associate(test(ioContext), scope.get_token());

works and also via

    co_await stdexec::spawn_future(
        test(ioContext),
        scope.get_token(),
        stdexec::prop(stdexec::get_scheduler, stdexec::inline_scheduler{})
    );

while

    co_await stdexec::starts_on(stdexec::inline_scheduler{}, stdexec::associate(
        test(ioContext),
        scope.get_token()));

deadlocks.

Is this simply not possible via stdexec::associate outside of a exec::task which also stores the result similar to a future or am I just e.g. setting the schedulers incorrectly?