-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Integrate event loops of runBlocking and UNCONFINED #860
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
Comments
Note, that Consider a regular function with an injected coroutine context
We are writing a test for it like this:
Wrapping this test function into a
|
…chers - Event loop that is created by runBlocking or by Unconfined dispatcher is reused across the same thread to prevent blocking of the loop - Semantics of runBlocking and Unconfined are fully retained - DefaultExecutor also registers itself as running event loop and thus cannot be blocked by runBlocking - Consolidates thread-local handling for native - Also fixes thread-local memory leak on JVM (does not use custom class) Fixes #860
…chers - Event loop that is created by runBlocking or by Unconfined dispatcher is reused across the same thread to prevent blocking of the loop - Semantics of runBlocking and Unconfined are fully retained - DefaultExecutor also registers itself as running event loop and thus cannot be blocked by runBlocking - Consolidates thread-local handling for native - Also fixes thread-local memory leak on JVM (does not use custom class) Fixes #860
…chers - Event loop that is created by runBlocking or by Unconfined dispatcher is reused across the same thread to prevent blocking of the loop - Semantics of runBlocking and Unconfined are fully retained - DefaultExecutor also registers itself as running event loop and thus cannot be blocked by runBlocking - Consolidates thread-local handling for native - Also fixes thread-local memory leak on JVM (does not use custom class) Fixes #860
…chers - Event loop that is created by runBlocking or by Unconfined dispatcher is reused across the same thread to prevent blocking of the loop - Semantics of runBlocking and Unconfined are fully retained - DefaultExecutor also registers itself as running event loop and thus cannot be blocked by runBlocking - Consolidates thread-local handling for native - Also fixes thread-local memory leak on JVM (does not use custom class) Fixes #860
…chers - Event loop that is created by runBlocking or by Unconfined dispatcher is reused across the same thread to prevent blocking of the loop - Semantics of runBlocking and Unconfined are fully retained - DefaultExecutor also registers itself as running event loop and thus cannot be blocked by runBlocking - Consolidates thread-local handling for native - Also fixes thread-local memory leak on JVM (does not use custom class) Fixes #860
The problem is that the code that uses
runBlocking { ... }
to provide integration for blocking Java APIs (like blocking IO) can deadlock when being run inside anotherrunBlocking { ... }
(see ktorio/ktor#672 for a real-life problem in Ktor that is causes). To avoid that, a nestedrunBlocking
shall use the same event queue as the outerrunBlocking
. The same is true forDispatchers.UNCONFINED
. There should be at most one active event queue per each thread for the purposes ofrunBlocking
andUNCONFINED
, which would allow to mix them in a deadlock-free way.One test that shows the problem is:
The text was updated successfully, but these errors were encountered: