My problem is it gets closed to early, before this implementation we tried with `any` but the channe...

# coroutines

[dave08]

My problem is it gets closed to early, before this implementation we tried with any but the channel was closed before the offer in the callback being wrapped...

[elizarov]

Because you did not suspend the`produce`. See my answer above. You should wait for cancellation inside produce after the callback is set

[elizarov]

define:

suspend fun awaitCancel(): Nothing = suspendCancellableCoroutine {}

[dave08]

Oh, thanks!

[elizarov]

https://github.com/Kotlin/kotlinx.coroutines/issues/289

[dave08]

Now we did this:

suspend fun awaitCancel(): Nothing = suspendCancellableCoroutine {}

suspend fun registerBroadcastReceiver(context: Context, intentFilter: IntentFilter): ReceiveChannel<Intent> =
        produce<Intent>(capacity = Channel.UNLIMITED) {
            var broadcastReceiver:BroadcastReceiver? = null
            try {
                broadcastReceiver = object : BroadcastReceiver() {
                    override fun onReceive(context: Context, intent: Intent) {
                        offer(intent)
                    }
                }.also {
                    context.registerReceiver(it, intentFilter)
                    awaitCancel()
                }
            } catch(e: CancellationException) {
                context.unregisterReceiver(broadcastReceiver)
            }
        }

But it's still not suspending, it just continues on with the code...

[deviant]

i use delay(Long.MAX_LONG) for such cases. probably not the best solution though 🙂

[elizarov]

Maybe delay(Long.MAX_LONG) overflows or something like that (and does not wait)

[deviant]

hmm. what do you mean by overflows?

[elizarov]

There was a bug with that some time in the past. Should have been fixed, but who knows.

[elizarov]

Test delay(Long.MAX_LONG) separately and if it does not wait report a separate issue about it, please

[deviant]

oh, android. i remember that brilliant fix with /2 🙂

[elizarov]

Overflows as in the following code:

val deadline = curTime + timeout //MAX_LONG !!
// so deadline is negative
whiile (curTime < deadline) wait() // aha!!!
//

[deviant]

now it works as expected

[dave08]

I think it's not waiting with awaitCancel... when we did it with delay it worked...?

[elizarov]

That is strange. suspendCancellableCoroutine {} should wait properly. No chance for it to wakeup, but on cancellation

[elizarov]

(no one is there to resume, since we are not even storing its continuation anywhere)

[dave08]

Here's the current code:

suspend fun registerBroadcastReceiver(context: Context, intentFilter: IntentFilter): ReceiveChannel<Intent> =
        produce<Intent>(capacity = Channel.UNLIMITED) {
            var broadcastReceiver:BroadcastReceiver? = null
            try {
                broadcastReceiver = object : BroadcastReceiver() {
                    override fun onReceive(context: Context, intent: Intent) {
                        offer(intent)
                    }
                }.also {
                    context.registerReceiver(it, intentFilter)
                    awaitCancel()
                }
            } finally {
                context.unregisterReceiver(broadcastReceiver)
            }
        }

[dave08]

Maybe we're doing something wrong?

[elizarov]

Maybe. Can you reproduce this problem in some self-contained example?

[dave08]

This just hangs @elizarov: https://gist.github.com/dave08/0cbbc5545732e280109ebffbe497ec7d

[dave08]

Now I corrected it (I hope), but the first test still hangs...

[elizarov]

I’m looking at at

[elizarov]

In your first test you you first suspend in channel.any, then you try to send(“hello”) there

[elizarov]

You should test it like this:

val result = async {
        channel.any {
            if (it.action == "hello") {
                channel.cancel(); true
            } else false
        }
    }
    context.send("hello")
    assert(result.await())

[dave08]

That seems to work, thanks!

[dave08]

What's funny is that the test still isn't recreating the exact situation in the app, it's still not suspending there... I guess I'll try working on it in the next few days... if I notice any edge cases, I'll report them back then, thanks anyways.