is anyone able to dispatch to a background queue f...

# kotlin-native

[Kris Wong]

is anyone able to dispatch to a background queue from kotlin? it looks like the lambda that you pass it needs to be frozen?

[Kris Wong]

Uncaught Kotlin exception: kotlin.native.IncorrectDereferenceException: illegal attempt to access non-shared com.airwatch.test.SendTestRunnerTestIos.$concurrency test$lambda-0$FUNCTION_REFERENCE$5@3e40b0e8 from other thread

[Kris Wong]

I am trying to emulate a call from an iOS app, but I can't do that if the lambda has to be frozen

[Kris Wong]

weird, freezing it doesn't even seem to fix it

[Kris Wong]

ah, needed to move the block back in the parens

[kpgalligan]

You definitely need to freeze the block (which freezes whatever it captures, just FYI)

[Kris Wong]

i'm aware, unfortunately

[Kris Wong]

this implementation is so nice and straightforward for JVM, and now I am going to have to introduce a bunch of complexity to get it working on native

[kpgalligan]

I’m working on a plugin to give you a heads up on captured state. The general solution is to cut down on the state you’re capturing in the lambda. I don’t know what you’re working on, so that may indeed make things ugly, but in most cases it hasn’t been too bad. The big exception being when you capture fields of a model class. You wind up freezing a bunch of things

[Kris Wong]

i have an object that is essentially a homegrown test runner, and it has one method that is designed to be called by the app from a brackground thread, but that whole idea just doesn't work for Native

[Kris Wong]

because even referencing the runner from a background thread is an exception

[kpgalligan]

The object itself is created in another thread?

[Kris Wong]

it's created on the main thread

[kpgalligan]

Would need to see it to comment more, but it sounds like a thing that would get complex with native.

[Kris Wong]

indeed it is

[Kris Wong]

i am going to start by exploring returning a frozen object that can use coroutines to transfer control back the main thread... but i know that having to freeze things will likely end up making this a no go

[Kris Wong]

yep, the job is getting frozen, and the job must be mutable

[kpgalligan]

If there’s a way to show some code, would be easier to comment on

[Kris Wong]

i can probably piece the important parts together into a gist

[Kris Wong]

it's a little messy because i've been trying to hack together something that works... https://gist.github.com/wongk/d770b899acbce719cba6294e719df28e

[kpgalligan]

There’s a lot going on there for sure. When you say “Job” you mean the thing you’re trying to run, not the coroutine “Job” right? In this piece of code, what is being frozen that you would expect not to be?

[Kris Wong]

no, i mean the coroutine job

[Kris Wong]

it's frozen, and it can't work that way

[kpgalligan]

What if you use the multithreaded coroutines?

[Kris Wong]

however, I was able to move the coroutine scope declaration to the companion object, and that fails differently (it hangs, I assume because I am reading from and sending to the channel both on the main thread)

[Kris Wong]

multithreaded coroutines carry all the same restrictions as worker... which will essentially mean I will have to completely refactor this class

[kpgalligan]

By restrictions do you mean the state/freezing?

[Kris Wong]

yes

[kpgalligan]

Well, I feel like you’re going to have a really hard time doing significant concurrency work in native and not refactoring, but I guess it depends how you do it

[Kris Wong]

i've exhausted my options for not refactoring w/o finding a solution

[Kris Wong]

(that can think of, anyway)

[Kris Wong]

i was hoping somehow some run loop magic or something would allow both ends of the channel to be used on the same thread

[kpgalligan]

Don’t know. I’m not super experienced with channels

[Kris Wong]

i can tell you it deadlocks 😛

[kpgalligan]

Running into similar. Concurrent testing is not fun

[Kris Wong]

hot damn ... reading this I think the new coroutines preview can support my use case

[Kris Wong]

https://github.com/Kotlin/kotlinx.coroutines/blob/native-mt/kotlin-native-sharing.md

[Kris Wong]

All core communication and synchronization objects in kotlin.coroutines such as Job, Deferred, Channel, BroadcastChannel, Mutex, and Semaphore are shareable. It means that they can be frozen for sharing with another thread and still continue to operate normally.

[Kris Wong]

a channel is exactly what I need to share

[kpgalligan]

Oh, yeah. That’s what I was tallking about. We’re using that in some almost-prod code

[Kris Wong]

this is an internal tool so I am not concerned about it's experimental state

[Kris Wong]

oh my lord it worked

[Kris Wong]

all I need to do is add 1 extra class to wrap the channel that can be used from non-main threads

[kpgalligan]

Nice