if i'm using a JNI/native library, and the jvm crashes (`SIGSEGV (0xb)`, `C [libsystem_pthread.dyli...

# coroutines

[conner]

if i'm using a JNI/native library, and the jvm crashes (SIGSEGV (0xb), C [libsystem_pthread.dylib+0x15ad] pthread_mutex_lock+0x0) when the value is created outside of a callbackFlow but not when it's inside, what would that mean? in other words,

val thing = createNativeThing()
callbackFlow {
  thing.onCallback = {
    offer(it)
  }
  thing.start()
}

crashes but

callbackFlow {
  val thing = createNativeThing()
  thing.onCallback = {
    offer(it)
  }
  thing.start()
}

does not

[conner]

my current guess is something to do with threading, but the library claims to be thread safe

[groostav]

yeahhh so the question is does the callbackFlow factory move threads, and I think the answer to that is yes. So probably what your seeing is createNativeThing() being on thread A and setOnCallback being on thread B, which might be giving it some trouble

[conner]

hmm, thanks, that makes sense. is there any way around this, particularly if I need thing to exist outside of the flow?

[groostav]

You might try Dispatchers.Unconfined, im still new to flows som not sure how you'd tell callback flow thats what you want

[groostav]

maybe callbackFlow{ ... }.flowOn(Dispatchers.Unconfined)

[groostav]

i dont think thats a great solution though,

[groostav]

A better solution might be to create your own thread and use thread isolation for your native library

[groostav]

val myThread = ExecutorService().asDispatcher()

val thing = withContext(myThread) { createNativeThing() }

callbackFlow { 
  withContext(myThread){
    thing.onCallback = { offer(it) }
    thing.start()
  }
}.flowOn(myThread)

[groostav]

the flowOn might not be necessary

[groostav]

the idea is to try to keep all of your interactions with native code in the therad myThread

[conner]

interesting -- thank you! i'll try that

[conner]

that worked! (and without the flowOn, for future reference)

[tseisel]

It seems that you omitted to call awaitClose at the end of the callbackFlow block. Is it on purpose ?

[conner]

i left it out in the example, but even in the real code it was just awaitClose {} -- would that be related?