`yield()` to run pending coroutines does not seem to work on Kotlin Playground, wonder why is that

# coroutines

[Patrick Steiger]

yield() to run pending coroutines does not seem to work on Kotlin Playground, wonder why is that

[jw]

Note that yield is not guaranteed to actually do that, depending on the dispatcher

[Patrick Steiger]

@jw I noticed from docs, but still even when using Dispatchers.Default I don’t see it working, I’m not even sure it’s suspending at all

[Patrick Steiger]

https://pl.kotl.in/PA3fCAFpx

[Patrick Steiger]

Same code on local JVM seems to consistently print “coroutine started”

[jw]

It probably runs in a container/cgroup that only has access to a single virtual CPU core

[jw]

So the number of threads is different and that causes different behavior

[jw]

Usually it's cores+1 though

[Dmitry Khalanskiy [JB]]

Dispatchers.Default is a multi-threaded dispatcher, so yield just means "relinquish the thread." However, the coroutine launch-ed is likely going to use a different thread. So, what happens here is a race: if, after the yield, the cancel manages to finish before the coroutine actually starts, the coroutine will not be run. So, there are no guarantees one way or another for whether yield helps here.

[Dmitry Khalanskiy [JB]]

For example, see https://pl.kotl.in/Sz_zergdF

[Patrick Steiger]

Makes sense. Using newSingleThreadContext(“single thread”) on playground eliminates the race it seems

[Dmitry Khalanskiy [JB]]

In this example, the withContext coroutine does not relinquish its thread at all, but with enough time, another thread is provisioned.

[Patrick Steiger]

Yeah, mystery solved. @Dmitry Khalanskiy [JB] I think it’s fair to say that when using a single threaded dispatcher, yield will always run the pending coroutine with no risk of races ?

[Dmitry Khalanskiy [JB]]

In practice, yes. In theory, you can implement a dispatcher any way you want, including randomly choosing which task to run next.

[Patrick Steiger]

Gotcha. Thanks y’all!