https://kotlinlang.org logo
Title
s

spierce7

09/22/2020, 1:32 AM
I believe at one point there was a way to create a dispatcher or a context that borrowed threads from another dispatcher, but also ensured that only one thread was accessing the coroutine at a time. Was that ever implemented?
z

Zach Klippenstein (he/him) [MOD]

09/22/2020, 1:40 AM
The
Default
and
IO
dispatchers share threads, but all the implementation details are internal I believe. In general, you shouldn’t need a dispatcher for this, just use a semaphore or worker pool or something to limit concurrency at a higher level.
s

spierce7

09/22/2020, 1:44 AM
right - then I’m creating my own threads though
I mean - it’s not the end of the world -
private val scope = CoroutineScope(Executors.newSingleThreadExecutor(DaemonThreadFactory).asCoroutineDispatcher())
z

Zach Klippenstein (he/him) [MOD]

09/22/2020, 1:47 AM
then I’m creating my own threads though
What do you mean? Using a semaphore/worker pool doesn’t create new threads.
s

spierce7

09/22/2020, 1:49 AM
by worker pool I assumed you were talking about a thread pool.
maybe those are what I’m looking for
@Zach Klippenstein (he/him) [MOD] Not seeing anything about WorkerPool
z

Zach Klippenstein (he/him) [MOD]

09/22/2020, 1:50 AM
No, “worker pool” is a just pattern where you create n coroutines and spread work among those coroutines, e.g. by sending work through a channel that they’re all listening to.
s

spierce7

09/22/2020, 1:51 AM
oh - I see
semaphore seems more annoying in this case than just having a single threaded coroutine, don’t you think?
I also saw ExperimentalCoroutineDispatcher in the library that allows to create limited dispatcher on it
z

Zach Klippenstein (he/him) [MOD]

09/22/2020, 11:15 AM
semaphore seems more annoying in this case than just having a single threaded coroutine, don't you think?
I'm not sure what you mean by "annoying". These are significantly different approaches with different tradeoffs. Threads are heavy and expensive, and one of the major benefits of using coroutines is that you don't need to create lots of them. The semaphore and worker approaches are much lighter weight since they can use the existing thread pools. They may or may not also make your code clearer, since they allow you to be more explicit about which parts of your code actually require synchronization.
j

Joffrey

10/06/2020, 3:18 PM
only one thread was accessing the coroutine at a time
@spierce7 I’m not sure I understand. How could a single coroutine be executed by multiple threads at a given time? To make an analogy, your sentence sounds to me just like “only one core executing the thread at a time”. Do you mean that a group of coroutines would be confined to a single thread? (and thus you’re looking for a single-threaded dispatcher that shares his only thread with other dispatchers?)
s

spierce7

10/06/2020, 3:48 PM
@Joffrey Sorry, I think you misunderstand.
I’m talking about using the default context, but limiting it so that only a single thread was able to access inside a coroutine context at a time. It was mentioned on an issue a few years ago and I was curious if it was ever implemented. I might be getting details wrong, but at the very least there was thread sharing between dispatchers.
j

Joffrey

10/06/2020, 4:00 PM
Yes I’m pretty sure I have misunderstood the initial question 😄 , so I take it that the re-phrasing of the question in my comment also doesn’t match what you’re looking for? If you have a single coroutine (like you seem to mention), there cannot be 2 threads executing it _at the same time_:
GlobalScope.launch(Dispatchers.Default) {
   delay(100)
   doSuspendingWork()
   delay(200)
}
After each suspending call here, a different thread could take over the execution of the (single) coroutine, but there is never 2 threads executing any piece of this at the same time. Is your issue about multiple coroutines instead (e.g. multiple nested
launch
)? Or do you mean that you would like this coroutine to be always resumed on the same thread after each suspension?
s

spierce7

10/07/2020, 1:10 PM
I mean that the coroutine can only be run accessed by a single thread at any given time, but it isn’t necessarily the same thread
I believe this might have been what I was referencing - https://github.com/Kotlin/kotlinx.coroutines/issues/261