Is there a possibility that recent kotlinx.coroutines versions (e.g. 0.23.3) play worse with proguard than previous ones (like 0.22.5)?

Direct invocation is always faster IMHO. Surprised you are doing that kind of low level stuff in Kotlin

I was thinking to a Channel but seems laborious

I am a huge fun of suspendCoroutine but sometimes I just to have a callback which signals me a value changed, I guess I need to provide it myself

are there unbounded channels?

Anyone have a good use case for using channels on Android? I'm trying to learn it, but I can't think in any good reason to use it on Android (Not saying that it doesn't exists tho)

In this example of actors from the guide. What ensures the memory safety of the

counter

variable ? ie. that the latest write to

counter

is always read by the next processing thread?

fun counterActor() = actor<CounterMsg> {
    var counter = 0 // actor state
    for (msg in channel) { // iterate over incoming messages
        when (msg) {
            is IncCounter -> counter++
            is GetCounter -> msg.response.complete(counter)
        }
    }
}

but for that I needed to add maven { url "https://dl.bintray.com/kotlin/kotlin-dev" }

Hi, anyone knows why there's no

onEach

function for

ReceiveChannel

?

Also, is there any alternative?

Specifically I'm talking about getResult() from firebase firestore. It throws an exception if the task isn't completed, and they have "add listener" crap that you can use, but I'd like to just call something like getResult in the commonpool context and have it suspend until the task is completed

This message was deleted.

I am using coroutines on Google App Engine. I have a coroutine dispatcher which uses the defined executor:

private fun defaultExecutor(): ThreadPoolExecutor {
    val maxPoolSize = Runtime.getRuntime().availableProcessors() * 3
    val keepAliveTime = 2L // in seconds
    val queue = LinkedBlockingQueue<Runnable>()
    return ThreadPoolExecutor(0, maxPoolSize, keepAliveTime, TimeUnit.SECONDS, queue, ThreadManager.currentRequestThreadFactory())
  }

Note the use of the

ThreadManager.currentThreadRequestFactory()

. Every time I invoke a

suspend

function I ensure that it is accompanied by a

withContext(...)

which uses the above defined coroutine dispatcher. I see that sometimes, I get `Exception`s on App Engine, claiming I am trying to get an instance of supporting services (like Datastore or Memcache) on a thread which was not created by their thread factory (

ThreadManager

). This typically happens in a coroutine's

resume

method. Any ideas on what I might be doing wrong ?

I want to use a language interpreter written for Java (LuaJ) and allow it to launch program execution (interpretation) on Kotlin coroutines. As far as I understand, it is impossible to get that functionality by just using the library from Kotlin. What would be the easiest way to make it work with Kotlin?

notice: I mean that I want to use Kotlin coroutines to launch many interpreters simultaneously, that is not about Lua coroutines

Why is the last

log

showing a

DefaultExecutor

context and not

SINGLE-THREAD

?

I have a process that has multiple steps. Think: fetching data from the database, doing some lookups, asking for input, and then performing some actions. Any of these actions could result in the entire process being cancelled (ideally with a specific error), but I also want to be able to relay the progress back. Is an actor a good use case for this?

Are there any tools, released or otherwise, that help debug coroutine stack-traces?

@nwh an actor would be a fine approach if they need to be serially executed

can we add this to the documentation?

Hi, do Android people there know if it's possible to make a Handler run in CommonPool?

Is it possible to wrap an async api based on polling (instead of callbacks) in a suspend function(or coroutine)? ...without another thread of course. So only

makeRequest(): Request

,

Request.isDone(): Boolean

,

Request.cancel()

and

Request.getResult(): Result

are available.

@elizarov I have a question about exception propagation. I can see that

handleCoroutineException()

tries to forward/handle the exceptions. So my question is: is the call to

handleCoroutineException()

generated by the compiler? maybe as part of the

Continuation

or by wrapping the state machine with a trycatch?

I am observing intriguing behavior with kotlinx.coroutines 0.23.4 where I call

job.cancel(IllegalStateException(...))

from a callback, catch exceptions from the parent coroutine, but still get my app crashing. I replicated the issue in some tests, and the catch block is hit, but it seems the Exception is thrown no matter if it was caught in the parent coroutine. Is this really intended?

Has anyone experienced Android instrumented test methods that have

runBlocking

as their body, never returning while the inner coroutine is run successfully?

Ahh, that's what I didn't understand, I think. If I used an actor, I would pass the channel it created to the task. It wouldn't go the other way, right?

@groostav Use a private constructor that takes the already initialized data, and in the companion object, declare a

suspend operator fun

that does what you need without blocking.

I would love to use coroutines in an OSGI bundle. Are there any plans to publish a coroutines bundle or include it into the kotlin bundle?

I'm almost certain I know the answer to this, but just in case: Is it possible to specify the type of CoroutineScope for a given CoroutineDispatcher or a CoroutineContext? For example, a context/dispatcher for a database that will pass the connection to the scope?

My team is already busy filling in other library gaps we have for MPP. We'll actually be pretty happy when we get kotlinx.coroutines that can work on background threads for kotlin/native. I'm more or less just curious when we were going to see something materialize on the cold streams front. I was expecting the answer of Q4 this year or Q1 2019. I'm fine with waiting.