https://kotlinlang.org logo
Join Slack
Powered by
I believe at one point there was a way to create a...
# coroutines
s
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
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
right - then I’m creating my own threads though
I mean - it’s not the end of the world -
Copy code
private val scope = CoroutineScope(Executors.newSingleThreadExecutor(DaemonThreadFactory).asCoroutineDispatcher())
z
then I’m creating my own threads though
What do you mean? Using a semaphore/worker pool doesn’t create new threads.
s
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
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
oh - I see
semaphore seems more annoying in this case than just having a single threaded coroutine, don’t you think?
b
I also saw ExperimentalCoroutineDispatcher in the library that allows to create limited dispatcher on it
z
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
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
@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
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_:
Copy code
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
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
Open in Slack
PreviousNext
Powered by