I've got a JVM process using coroutines 1.0.0 that has a thread like this that appears to be in a tight loop and using 100% CPU:

"DefaultDispatcher-worker-5" - Thread t@95
   java.lang.Thread.State: RUNNABLE
	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
	- locked <1c724d56> (a sun.nio.ch.Util$3)
	- locked <2daa5d57> (a java.util.Collections$UnmodifiableSet)
	- locked <69cba374> (a sun.nio.ch.EPollSelectorImpl)
	at sun.nio.ch.SelectorImpl.selectNow(SelectorImpl.java:105)
	at io.ktor.network.selector.ActorSelectorManager.process(ActorSelectorManager.kt:76)
	at io.ktor.network.selector.ActorSelectorManager$process$1.invokeSuspend(ActorSelectorManager.kt)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:32)
	at kotlinx.coroutines.DispatchedTask$DefaultImpls.run(Dispatched.kt:235)
	at kotlinx.coroutines.DispatchedContinuation.run(Dispatched.kt:81)
	at kotlinx.coroutines.scheduling.Task.run(Tasks.kt:94)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:586)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.access$runSafely(CoroutineScheduler.kt:60)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:732)

   Locked ownable synchronizers:
	- None

"DefaultDispatcher-worker-5" - Thread t@78
   java.lang.Thread.State: TIMED_WAITING
	at sun.misc.Unsafe.park(Native Method)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.doPark(CoroutineScheduler.kt:835)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.cpuWorkerIdle(CoroutineScheduler.kt:813)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:721)

   Locked ownable synchronizers:
	- None

It isn't executing any application code, just continuously parking/unparking, AFAICT. How can I tell what is going on here and why this has happened?

I have some simple code like the above, im trying to migrate to 1.3 now though and can't see what I would migrate Job to? I am quite new to coroutines so excuse me if it's a silly question

I need some introduction into more advanced parts of coroutines. Just for simplicity let’s assume that we have 3 views that are retrieving the same data from repository (so 3 views are calling the same repository method at the same time). This repository method under the hood makes a network call, so we don’t want to make multiple requestes:

View1 calls repos.getData() - start downloading data
View2 calls repos.getData() - data download in progress so just wait for result
View2 calls repos.getData() - data download in progress so just wait for result

How this can be achieved?

Question about coroutines. Why this code doesn't work in case of a channel that is closed at the sender side? If I add the commented delay() the

isClosedForReceive

has more chances to be updated and stop the cycle, otherwise, it won't and I get an exception. Basically, there's a race condition on the

isClosedForReceive

property that doesn't allow me to use it as a condition for stop receiving.

while (!kotlinChannel.isClosedForReceive) {
      val data = kotlinChannel.receive()
      delay(1) // NEEDED IN ORDER TO UPDATE (most of the time) isClosedForReceive
      println(data)
    }

Thank you @jw, with your extension plus this one:

suspend fun suspendCoroutineWithoutReturn(fn: (Continuation<Unit>) -> Unit) = suspendCoroutine(fn)

I was able to get exactly what i wanted:

suspend fun <T : AppCompatActivity> T.awaitRunOnUi(fn: T.() -> Unit) {
    suspendCoroutineWithoutReturn { continuation ->
        runOnUiThread {
            fn()
            continuation.resume()
        }
    }
}

Do I understand correctly that if I have coroutine, and other sub-coroutines inside it, and I "cancel" (exit) it, the gargbage collector does cleaning up all the sub-co-routines (sorry for confusing terminology)

With kotlinx-coroutines-io-jvm 0.1.0-beta1 I used to have code that did

ByteReadChannel.lookAheadSuspend

in which I was able to call

consumeEachRemaining

, like this:

fun CoroutineScope.flowableOf(byteReadChannel: ByteReadChannel): Flowable<ByteBuffer> = rxFlowable {
  byteReadChannel.lookAheadSuspend {
    consumeEachRemaining {
      send(it.copy())
      true
    }
  }
}

In kotlinx-coroutines-io 0.1.0, this same code compiles but does not work -- it does not read the entire channel. Neither does the corresponding non-suspending

lookAhead

method work.

For example

val rootJob = Job()
val rootContext = Dispatchers.Default + rootJob

val otherJob = Job()
val otherScope = object : CoroutineScope {
    override val coroutineContext = rootContext + otherJob
}
otherScope.doSomethingAsync()
otherScope.doSomethingElseAsync()

rootJob.cancel() // will this cancel items from otherJob?

Is there a version of

Job

that can be created similar to

fun Job(parent: Job? = null)

where

cancelsParent = false

Suppose I have this structure:

suspend fun functionA() {
    // A1
    functionB()
    // A2
}

suspend fun functionB() {
    // B1
    delay(1000)
    // B2
}

where

A1

,

A2

etc denote normal, non-suspending code blocks. I'm trying to understand how these code blocks are scheduled on the available threads. Suppose

functionA

is currently executing on some thread

T1

, using a dispatcher that has multiple threads available. The call to

functionB

is a suspension point - is it correct to say that at that point, executing of my code may be suspended to allow some other work to be done on

T1

? In that case, does that also mean that

B1

can be scheduled on a different thread? I'm pretty sure this happens around the call to

delay

, but I'm uncertain about my own code. Similarly, what about

B2

and

A2

? Are they guaranteed to be executed on the same thread, or is exiting a suspending function also a suspend point?

Hi. In the early versions of Coroutines, there were the usual Coroutines Builders, but now in version 1.0.1, methods: launch, asynch extensions of CoroutineScope. Are there any explanations or examples of which CoroutineScope should be used?

Hello! We have just upgraded kotlin and coroutines for our service. One thing noted was that main can now be a suspend method. What happens if main gets suspended? Is there any considerations when having long-lived applications? (previously we did a runBlocking { application.start() }, now we just do application.start())

Why isn't this enough for IntelliJ to stop warning about experimental usages of kotlinx.coroutines?

is Dispatchers.IO correct coroutine context to execute sql db queries in ktor app?

Is there an easy way to get everything what is currently in a channel? For example if I do something like

channel.take(10)

and there are currently only 8 elements, I want to have those 8 elements instead of waiting until it hits 10

It's doing other enqueued work

Still trying to wrap my head around how suspending functions and coroutines come into play in a full complete production grade app (non android)

Something that does more than just call delays would be nice lol

Hi, for testing is there anyway to make my unit tests work if I use

Dispatchers.Main

dispatcher, or do I need to mock that guy? I'm getting

java.lang.IllegalStateException: Module with the Main dispatcher had failed to initialize

Hi, am I right that any failing

async

(and

launch

) block in an

actor

will close the

actor

and make it stop accepting anything?

Wouldn't it be enough to add a new Job to the async context @louiscad?

Is it better to be using a coroutineScope when all there is is one operation there? To be truthful, I made my own

launchInScope

function to do the same thing... just wondering if that's really the intention. If so, why not just abstract away the whole Job concept and let the end user deal only with scopes?

Hi guys, can someone please tell me how to disable warnings in IntelliJ for

ExperimentalCoroutinesApi

when using maven? (the following is obviously not working)

<configuration>
	<args>
		<args>-Xuse-experimental=kotlin.Experimental</args>
		<args>-Xuse-experimental=kotlinx.coroutines.ExperimentalCoroutinesApi</args>
		<args>-Xuse-experimental=kotlinx.coroutines.ObsoleteCoroutinesApi</args>
	</args>
</configuration>

which is the best approach for an offline first approach?

Case: I have to fetch from api (if fails)> from cache (if fails) -> catrastrophic failure handling

So first case would be something like Using lambdas

fun getContent(){
		launch{
		    try{
		    val content =useCase.getContent(errorLambdaCallback= {handleError(it)})
			showContent(content)
			} catch(e:Exception){
			  handleError(e)
			}
		}
	}

Or use channels to communicate back that some error happened but the cache is retrieved? or there is actually a better way to handle this case where I need to handle error and get the content

In this snippet, the theoretical resource is not released, when the coroutineContext is cancelled before

produce

has been started. Is it possible to avoid this race?

the only way to prevent a crash is add a try block inside

someFunctionThatCrash

Can any1 explain this behavior to me please?

FYI this is a good reason not to use exceptions as a way to control flow. Use sealed classes

If your function is marked suspend then you are calling it from a coroutineScope already. So it's maybe better to do

suspend fun fetchCharacterData(): CharacterGenerator.CharacterData = {
            val apiData = withContext(<http://Dispatchers.IO|Dispatchers.IO>) { URL(CHARACTER_DATA_ENDPOINT).readText()} 
            CharacterGenerator.fromApiData(apiData)
        }

to start on good bases.

So finally went to prod with coroutines 🙂 I'm just facing a rare crash for the moment on a specific device (Galaxy Tab Android 5.0.2) have anyone saw this one before?