Structured concurrency & Job cancellation improvements #1020
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BREAKING BEHAVIOR CHANGE:
* kotlinx-coroutines-jdk8 and -guava integration modules
future { ... } builders now honor structured concurrency in
the same way as all other builders -- a failure inside the child
(builder) code now cancels parent coroutine.
Note that is does not affect non-structured (typical) usage like
GlobalScope.future { ... }
MINOR BEHAVIOR CHANGE:
* Exception in installed CancellableCoroutine.invokeOnCancellation
handler does not cancel the parent job, but is considered to be an
uncaught exception, so it goes to CoroutineExceptionHandler.
Internal changes:
* JobSupport.cancelsParents=true is now a default, since there are
only a fewer exceptions for builder that throw their exception from block
* JobSupport.handleJobException has additional "handled" parameter to
distinguish cases when parent did/did-not handle it.
* handleCoroutineException logic is updated. It never cancels parent,
since parent cancellation is taken care of by structured concurrency.
* handleCoroutineException is always invoked with current coroutine's
context (as opposed to parent)
Fixes #1007
Job/ReceiveChannel/BroadcastChannel.cancel(Throwable) is now hidden and cannot be invoked from a newly compiled code. This function had broken semantics when used with an arbitrary exception. A safe replacement is available in the form of cancel(CancellationException) where CancellationException can be used to supply additional information for debugging purposes. Fixes #975
qwwdfsad
requested changes
Mar 4, 2019
This simplifies trouble-shooting of "what caused cancellation", as you can print out exception and see its recovered stack trace.
elizarov
force-pushed
the
cancel-exception
branch
from
2898f01
to
d293639
Compare
And also make sure only the first detected error gets reported
elizarov
force-pushed
the
cancel-exception
branch
from
385881d
to
d202ed9
Compare
qwwdfsad
approved these changes
Mar 13, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Structured concurrency for Completable/Listenable futures
BREAKING BEHAVIOR CHANGE:
future { ... } builders now honor structured concurrency in
the same way as all other builders -- a failure inside the child
(builder) code now cancels parent coroutine.
Note that is does not affect non-structured (typical) usage like
GlobalScope.future { ... }
MINOR BEHAVIOR CHANGE:
handler does not cancel the parent job, but is considered to be an
uncaught exception, so it goes to CoroutineExceptionHandler.
Internal changes:
only a fewer exceptions for builder that throw their exception from block
distinguish cases when parent did/did-not handle it.
since parent cancellation is taken care of by structured concurrency.
context (as opposed to parent)
Fixes #1007
Hide cancel(Throwable), introduce cancel(CancellationException)
Job/ReceiveChannel/BroadcastChannel.cancel(Throwable) is now hidden and
cannot be invoked from a newly compiled code. This function had broken
semantics when used with an arbitrary exception. A safe replacement
is available in the form of cancel(CancellationException) where
CancellationException can be used to supply additional information
for debugging purposes.
Fixes #975