Is there something like <Touchlab's Stately Isolate> that wouldn't block the calling thread? Possibl...

# kotlin-native

[mbonnin]

Is there something like Touchlab's Stately Isolate that wouldn't block the calling thread? Possibly exposing a suspend interface?

[russhwolf]

can you just wrap it in a launch?

[russhwolf]

or a withContext

[mbonnin]

That'd still block a thread, right?

[mbonnin]

(even if not the main thread)

[russhwolf]

yeah it would, but not the calling thread if you change context

[mbonnin]

Yea I guess that'd work. I was wondering if someone ever tried to pass a continuation around and resume once the work is done

[mbonnin]

That'd use less threads under load (even if latency would most likely be similarly high)

[mkrussel]

I don't know of anything, but that sounds a bit like using coroutine actor.

https://kotlinlang.org/docs/shared-mutable-state-and-concurrency.html#actors

[russhwolf]

I don't remember the internals of isolate well enough to say for sure, but it seems like it should be possible to build something like that. But it would probably require a change to stately to provide a callback hook when the operation ends so you have a place to resume the continuation

[mbonnin]

👍 Will look into it

[mbonnin]

@mkrussel Looks like actor is now Obsolete ? https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.channels/actor.html

[russhwolf]

yeah I wouldn't go anywhere near actor for new code at this point. It's also JVM-only and they have no intention of porting the existing API to KMP before they do the API redesign that prompted the Obsolete annotation

[russhwolf]

Feel free to open an issue or PR on stately. It's been hard for us to justify putting a lot of dev cycles into it since it'll be obsoleted once the new memory model comes out, but that's still probably going to be a long time so if you have a good need and it's not too complicated of a change, we should look into it.

[mbonnin]

This is what I came up with: https://github.com/apollographql/apollo-android/blob/e80b3ab5430ad9ebadcf37cfdee62[…]apollographql/apollo3/cache/normalized/internal/IsolateGuard.kt
Pretty old school but seems to work 🤞

[kpgalligan]

Interesting. I'll have to take a longer look after I've had more coffee. Will think about the coroutines enabled version. It makes sense. Since the memory model changes were announced we haven't been putting a lot of future thought into Stately, but we'll see.

[kpgalligan]

Ah, main thread specific. HMM. Would need to think about that in a general context, but that's tricky. I assume that's why Ktor on iOS needs to be started from the main thread (or did. I'm always a version or 2 behind in my thinking).

[kpgalligan]

There's a class of things that would work well just for KMM. I tried keeping Stately broadly applicable, but there's maybe room for mobile specific ideas (Android/iOS can get to the main thread from anywhere, but JVM and others don't really have that concept/capability).

[kpgalligan]

Koin's native implementation is kind of KMM specific in that way.

[mbonnin]

The file I linked is main specific but maybe it doesn't need to be? I haven't looked too much into coroutines-native-mt but maybe the isolated thread could hold a stable ref to the calling dispatcher and dispatch the continuation using it?

[mbonnin]

Overall, I kind of like not depending on native-mt and I think the requirement to launch the coroutine in the main thread is a reasonable one if work can be easily delegated to other threads

[kpgalligan]

On native, non-main dispatchers are all worker-based (again, also, that may have changed since I looked). I guess you'd need some kind of interface that would let you schedule a resume

[kpgalligan]

I'd definitely need to dig into it. I'm talking from memory, which is not a great idea

[mbonnin]

From what I tried, continuations don't like being tunnelled through workers too much but it works with the pthread_ thingies. Maybe there's a way with workers though. That'll most like have a better queue mecanism that rewriting a mutable list into an AtomicReference all the time.

[kpgalligan]

Well, for a really simple solution that will only work on darwin/apple targets, I might suggest this: https://github.com/cashapp/sqldelight/blob/master/drivers/native-driver/src/native[…]tlin/com/squareup/sqldelight/drivers/native/util/NativeCache.kt

[kpgalligan]

private val dictionary = NSMutableDictionary() Just mutable native state wrapped with locks

[mbonnin]

Ah interesting! And that works because NSMutableDictionary is not a Kotlin object and it's ok to access the mutable object from different threads?

[kpgalligan]

Yeah, but now thread safety is your problem. Also, very important. NSMutableDictionary is fine, but any Kotlin objects that go in there must be frozen explicitly.

[mbonnin]

I see 👍 That sounds better than the Atomic stuff. Will dig into this, thanks!