i'm really interested in how the coroutine model will translate into that as well. i'm glad others are taking the plunge. i'm trying to follow along on issues and the like, but not getting my feet wet just yet.

Using ConcurrentHashMap can block a thread coroutine is running on

also, does anybody else things its strange that

select {}

will simply abandon your coroutine?

@Test fun `using an empty select clause just abandons you`() = runBlocking {

        val producer = produce<String> {
            select<String> {
                val x = 4;
            }

            val y = 4;
        }

        val result = producer.receiveOrNull()

        val z = 4;
    }

never completes

If I've created a threadpool using

newFixedThreadPoolContext

then will coroutines jump between threads like

Unconfined

?

What is the state of Exception stack recovery on resume with coroutines? On 1.2.51, 0.23.4, I'm seeing the first line of my stack as

doResume

within a class without a line number e.g.

at com.MyClass$withFoo$1.doResume(MyClass.kt) ~[classes/:?]

would appreciate any feedback

or does this cover that: https://github.com/Kotlin/kotlinx.coroutines/issues/280

This is an excerpt from Mutex.kt. I think

cont.initCancellability()

should be placed after

removeXXX

. Because if the coroutine was cancelled right after the init call, the waiter won't be removed.

I have a question about coroutines (in combination with android apis that have callbacks). Would this, or #android be the appropriate channel?

yes, just wondering if it will be merged in time for the 1.3 release. I guess I could have phrased that better.

Hmm, interesting, I see But also you can just call suspend function that can cache result under the hood

so after upgrading to 0.24.0 my unit tests started failing due to

java.lang.RuntimeException: Method myLooper in android.os.Looper not mocked. See <http://g.co/androidstudio/not-mocked> for details.

	at android.os.Looper.myLooper(Looper.java)
	at kotlinx.coroutines.experimental.android.MainLooperChecker.checkRunBlocking(HandlerContext.kt:124)

The tests are plain JVM unit tests and use

runBlocking

to test presenters

if i have an

async {
     while(isActive){
         ....
     }
    return "something"
}

how can I cancel it so that I can call

await

without getting a cancellation exception?

In case anyone missed the planned cold-streams work explanation: https://github.com/Kotlin/kotlinx.coroutines/issues/254#issuecomment-408379789

Very clear 🙂

Hi all, I'm looking for a simple coroutine-based event bus. I found this implementation https://gist.github.com/takahirom/f2dbcc3053adfd87ac7e321d95a23021 however I have an issue with it. It uses

ConflatedBroadcastChannel

which keeps the last sent item and delivers it to new subscribers in

openSubscription()

. I'm looking for an event bus implementation that does not cache items. So if an event is send but there are no active subscriptions the bus should just drop the event. Unfortunately there doesn't seem to be a default implementation of

BroadcastChannel

with these characteristics. Has anyone an idea how to implement a simple non-caching event bus?

hi, anyone have a good guide / blog posts or hints on writing a custom

CoroutineContext

? Context: In my android app, I have a “god” object that handles all the network api calls and responses (using callbacks), and has its own lifecycle of sorts: I’m trying to write a

CoroutineContext

that will allow me to write coroutines that dispatch to the

DefaultDispatcher

but are aware of the lifecycle of this god object

I’m having some issues using

asCompletableFuture

. It seems to hang if my coroutine throws an exception.

class CompletableFutureTest {
    @Test
    fun testFailAsCompletableFuture() {

        val executeJob = async {
            fail("Test failed predictably")
        }

        val future = executeJob.asCompletableFuture()
        println("### asCompletableFuture")
        future.get()
        println("### Execute job completed!")
    }
}

I get this stacktrace in the log

Exception in thread "ForkJoinPool.commonPool-worker-1 @coroutine#1" kotlinx.coroutines.experimental.CompletionHandlerException: Exception in completion handler InvokeOnCompletion[InvokeOnCompletion@377acc75] for "coroutine#1":DeferredCoroutine{CompletedExceptionally}@685fc50a
	at kotlinx.coroutines.experimental.JobSupport.completeUpdateState(JobSupport.kt:226)
	at kotlinx.coroutines.experimental.JobSupport.updateState(JobSupport.kt:157)
	at kotlinx.coroutines.experimental.JobSupport.makeCompletingInternal(JobSupport.kt:568)
	at kotlinx.coroutines.experimental.JobSupport.makeCompletingOnce$kotlinx_coroutines_core(JobSupport.kt:552)
	at kotlinx.coroutines.experimental.AbstractCoroutine.resumeWithException(AbstractCoroutine.kt:110)
	at kotlin.coroutines.experimental.jvm.internal.CoroutineImpl.resume(CoroutineImpl.kt:41)
	at kotlinx.coroutines.experimental.DispatchedTask$DefaultImpls.run(Dispatched.kt:150)
	at kotlinx.coroutines.experimental.DispatchedContinuation.run(Dispatched.kt:14)
	at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
	at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
Caused by: java.lang.AssertionError: Test failed predictably
	at org.junit.Assert.fail(Assert.java:88)
	at kotlin.test.junit.JUnitAsserter.fail(JUnitSupport.kt:56)
	at kotlin.test.AssertionsKt__AssertionsKt.fail(Assertions.kt:89)
	at kotlin.test.AssertionsKt.fail(Unknown Source)
	at completable.future.test.CompletableFutureTest$testFailAsCompletableFuture$executeJob$1.doResume(CompletableFutureTest.kt:14)
	at kotlin.coroutines.experimental.jvm.internal.CoroutineImpl.resume(CoroutineImpl.kt:42)
	... 7 more

Since runBlocking is now disallowed on Android (since 0.24.0), anyone got any experience on alternative mechanisms that can be used to bridge between the blocking world and the non-blocking world?

🙂 No worries, I appreciate your responses anyway, since if I come to use activities (in the future) - I have an answer! 🙂

Anybody work with go goroutines? I have a few questions about concepts and how similar they are to kotlin coroutines

after upgrading to Kotlin 1.2.60 I get weird compiler errors regarding `@RestrictsSuspension`:

@RestrictsSuspension
    class Foo() {
        suspend fun bar() = Unit
    }

    // ERROR: Restricted suspending functions can only invoke member or extension suspending functions on their restricted coroutine scope
    fun yUnoWork() = runBlocking { Foo().bar() }

This hasn't got an effective answer. I'm getting the same problem. Anyone can help?

Another request. I found LockFreeLinkedListHead/Node very useful in implementing custom locks. But these classes are currently in the internal package. Can we make it a public API?

No

Hi, I'm working on an open source Android library that makes Camera2 API actually usable (with readable code) thanks to coroutines, and there are some places where it takes a

Handler?

. Since coroutines already have the concept of dispatcher, there's a kind of concept duplication (although

Handler

is single threaded, unlike `CoroutineDispatcher`s). I'd like to avoid this leaking into the API of my library as method parameters, so I'm thinking about putting the

Handler

into the

CoroutineContext

so it can be retrieved by the library. Do you think it's a good usage of

CoroutineContext

ThreadLocal-like abilities?

Are there established ways to convert various flavors of future (beyond

CompletionStage.asDeferred()

) into

Deferred

for use in

suspend

functions? If not, I can always adapt code from

asDeferred

, but if there’s something supported out there, might as well use it

Is there a way to stop Kotlin from ruining stack traces when suspending?

Can anyone please explain what

yield()

is doing?

@Test
    fun testLaunchAndYieldJoin() = runTest {
        expect(1)
        val job = launch(coroutineContext) {
            expect(3)
            yield()
            expect(4)
        }
        expect(2)
        assertTrue(job.isActive && !job.isCompleted)
        job.join()
        assertTrue(!job.isActive && job.isCompleted)
        finish(5)
    }