The problem with the "await"

[EdmondDantes]

Over the past few months of using the await function, it has become clear that it is quite inconvenient for coroutines.
There are no issues with Future objects, because a Future is just a state.

Suppose you create a coroutine and want to exit a block of code correctly in a way that allows you to handle any exceptions coming from the coroutine. In the TrueAsync RFC, this pattern is called a “Responsibility Point”. And you use await.

use function Async\spawn;
use function Async\await;

// Spawn a coroutine
$coroutine = spawn(function () {
});

try {
    // Await acts as a synchronization point
    // It suspends the current coroutine until the spawned one finishes
    await($coroutine);
} catch (\Exception $e) {
    // Responsibility point:
} finally {
    // Guaranteed cleanup
    cleanup();
}

Suppose the coroutine was cancelled. In this case, await will terminate. And then, if an exception occurs during cancellation, it will not be caught by the responsibility point.

Another similar scenario with a cancellation token: await($coroutine, new \Async\timeout(1));
The timeout expires, but the coroutine is still running.

The problem is that such code looks clean and logical, but in reality it leads to bugs if the programmer forgets that the coroutine continues to live its own life. And in 90% of cases, the programmer will forget about this. On the other hand, the logic of await here is classical and correct. await does not guarantee 100% completion of a coroutine; all it does is wait for completion or an exception.

I don’t want to redesign the logic of await, because it evolved this way historically and may be needed in some cases.

However, from the perspective of a more convenient API, I would prefer a function like join(), which works slightly differently:

1. join waits for the coroutine to finish 100%. It effectively creates a reliable responsibility point.
2. join cancels the coroutine if the cancellation token is triggered, and then waits for the coroutine to fully terminate.

Maybe someone else will have additional thoughts on this....

[xingye00186]

I don't fully understand the issue you mentioned, but regarding coroutine exceptions, I believe that it' s better to handle exceptions within the coroutine or its callback, preventing them from propagating to other coroutines or impacting the main program flow.

[AlliBalliBaba]

IMO you should only allow the join logic. Not propagating these failures up to the parent probably leads to bad control flow.

[lucaswitch]

I like the await behavior to be defined like you mentioned on the join example.

[EdmondDantes]

In version 0.7.0, the behavior of await for coroutines has changed.

Coroutines now propagate exceptions to their coroutine handle. In other words, if someone is holding a handle to the coroutine, the exception will no longer end up as a fatal error.

As a result, awaiting a coroutine now behaves consistently in all cases. await will receive the exception even if the coroutine completed before await was called.