Support for blocking calls inside coroutines (#79) #83
Conversation
fvasco
force-pushed
the
79-blocking-calls
branch
2 times, most recently
from
7ca7ffc to
f5acb73
Compare
fvasco
force-pushed
the
79-blocking-calls
branch
from
f5acb73 to
e9e6613
Compare
elizarov
force-pushed
the
develop
branch
5 times, most recently
from
0b13569 to
35d2c34
Compare
fvasco
force-pushed
the
79-blocking-calls
branch
from
e9e6613 to
9fccedc
Compare
| start: CoroutineStart = CoroutineStart.DEFAULT, | ||
| block: () -> T): Deferred<T> { | ||
| require(start != CoroutineStart.UNDISPATCHED) { "Start blocking code undispatched is not supported" } | ||
| return async(executor.asCoroutineDispatcher(), start) { block() } |
There was a problem hiding this comment.
Maybe we should cache dispatcher created from DefaultBlockingExecutor to avoid dispatcher creation on each call of the function and it would be helpful to have DefaultBlockingExecutor dispatcher (BlockingPool?) available as object same way as we have CommonPool.
Also, I'm not sure that it's good, that we don't allow to pass custom context here because context can be used not only for dispatchers.
| * @param executor the executor for blocking code | ||
| * @param block the blocking code | ||
| */ | ||
| suspend fun <T> blocking(executor: Executor = DefaultBlockingExecutor, block: () -> T) = |
There was a problem hiding this comment.
I think blocking should be covered by tests as well.
|
Hi @gildor, I wish receive some feedbacks about the future of this patch before continue the work. |
|
I'm sorry for dragging my feet for so long here. I did not saw it as improvement versus |
Added
blockingandblockingAsyncsuspending functions for blocking code invocation inside a coroutine.