so the above issue is actually rooted in using `CoroutineWor

Question

so the above issue is actually rooted in using `CoroutineWorker execute` with `CompletableDeferred` anyone have an idea why completing the deferred might deadlock when used from `execute`

basher · Answer

do you have a code sample

Kris Wong · Answer

i can distill it down into a basic example

Kris Wong · Answer

``` Test fun testSomething = runBlocking val deferred = CompletableDeferred lt Unit gt CoroutineWorker execute deferred complete Unit deferred await ```

Kris Wong · Answer

it deadlocks on `deferred complete`

basher · Answer

is this using native mt branch or something

Kris Wong · Answer

no

basher · Answer

that s going to freeze `deferred` then which could do bad things

basher · Answer

there s probably internal state you re freezing

basher · Answer

it may not be deadlocking as much as crashing on a bg thread and dying silently

Kris Wong · Answer

any problems from that would throw an exception would it not

basher · Answer

and then your main thread never finishes waiting on the deferred

basher · Answer

yes but exceptions in Worker do not crash the app

basher · Answer

they just log

Kris Wong · Answer

hmmm

basher · Answer

that s why CoroutineWorker has a special mechanism for capturing Worker exceptions so that you can manually crash if that s what you want

Kris Wong · Answer

i ve always gotten a stack trace when i ve had issues with freezing in the past

basher · Answer

you won t get the exception when you freeze you ll get it later in the background when you try to complete the deferred

Kris Wong · Answer

understood

basher · Answer

that function btw <https github com Autodesk coroutineworker blob master src nativeMain kotlin com autodesk coroutineworker BackgroundCoroutineWorkQueueExecutor kt L144>

basher · Answer

logs might show the exception assuming my guess is correct

Kris Wong · Answer

i ll give it a shot

basher · Answer

Best documentation I can find about worker uncaught exceptions is just the param for Worker start <https kotlinlang org api latest jvm stdlib kotlin native concurrent worker start html|https kotlinlang org api latest jvm stdlib kotlin native concurrent worker start html>

basher · Answer

IIRC it was just something we observed when testing things for our first App Store release

Kris Wong · Answer

the handler is not receiving an exception in this case

Kris Wong · Answer

well whatever the actual root cause is seems like I am going to be rolling my own kind of Deferred to fix this so I might as well just do that

Kris Wong · Answer

so strange now that s fixed something about `COROUTINE SUSPENDED` seems to cause the dead lock but now I have the same behavior with `Semaphore`

basher · Answer

What s COROUTINE SUSPENDED

basher · Answer

Semaphore also can t be frozen if you mean the one from coroutines lib

Kris Wong · Answer

it s a special value used with `suspendCoroutine`

Kris Wong · Answer

i replaced semaphore with the same class I used in place of deferred

Kris Wong · Answer

now it s all working

basher · Answer

Huh ok hand

Kris Wong · Answer

ツ