-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Async cancellation with structured concurrency #552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
Comments
For a long term evolution, I propose to support supervisor strategy with Akka or Erlang style, it's proofed. |
elizarov
added a commit
that referenced
this issue
Sep 27, 2018
* Affects async, CompletableDeferred, and all Rx integration builders. * This makes all coroutine builders totally consistent. They all cancel parent on failure, but they all consider "CancellationException" to be the case of "normal cancellation" that does not propagate to parent. The only missing case is Job() that should be fixed together with introduction of SupervisorJob(). * Note that "scoping" builders don't "cancel the parent", but rethrow the corresponding exception instead, so it that is how it gets propagated up the stack. * This makes parallel decomposition exception-safe. You cannot loose an exception as along as default (child async) behavior is not overridden. Fixes #552
elizarov
added a commit
that referenced
this issue
Sep 27, 2018
* Affects async, CompletableDeferred, and all Rx integration builders. * This makes all coroutine builders totally consistent. They all cancel parent on failure, but they all consider "CancellationException" to be the case of "normal cancellation" that does not propagate to parent. The only missing case is Job() that should be fixed together with introduction of SupervisorJob(). * Note that "scoping" builders don't "cancel the parent", but rethrow the corresponding exception instead, so it that is how it gets propagated up the stack. * This makes parallel decomposition exception-safe. You cannot loose an exception as along as default (child async) behavior is not overridden. Fixes #552
elizarov
added a commit
that referenced
this issue
Sep 27, 2018
* Affects async, CompletableDeferred, and all Rx integration builders. * This makes all coroutine builders totally consistent. They all cancel parent on failure, but they all consider "CancellationException" to be the case of "normal cancellation" that does not propagate to parent. The only missing case is Job() that should be fixed together with introduction of SupervisorJob(). * Note that "scoping" builders don't "cancel the parent", but rethrow the corresponding exception instead, so it that is how it gets propagated up the stack. * This makes parallel decomposition exception-safe. You cannot loose an exception as along as default (child async) behavior is not overridden. Fixes #552
elizarov
added a commit
that referenced
this issue
Sep 27, 2018
* Affects async, CompletableDeferred, and all Rx integration builders. * This makes all coroutine builders totally consistent. They all cancel parent on failure, but they all consider "CancellationException" to be the case of "normal cancellation" that does not propagate to parent. The only missing case is Job() that should be fixed together with introduction of SupervisorJob(). * Note that "scoping" builders don't "cancel the parent", but rethrow the corresponding exception instead, so it that is how it gets propagated up the stack. * This makes parallel decomposition exception-safe. You cannot loose an exception as along as default (child async) behavior is not overridden. Fixes #552
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Consider following code:
This code works as expected, but if one replaces
awaitAll(one, two)
withone.await(); two.await()
(e.g. to aggregate computed results), this code hangs forever.A cause of this hang is clear:
async
does not cancel its parent on a failure.But unconditionally cancelling parent may be undesired:
Now whether "Exception caught" is printed depends on the
Scope
object: forGlobalScope
it will be printed and forCoroutineScope(Job())
it will be not, which may lead to uncaught errors and user's confusion.Related to #220 and #515
The text was updated successfully, but these errors were encountered: