A modern programming language that makes developers happier.

kotlinlang

<@U3SK5B492> Any idea when you guys are going to be willing to talk about some of the proposed changes to the memory model? My team is trying to write common code that will be compatible with Kotlin/native in the future, and are very interested in the potential changes.

Current model of concurrency will not go away, so if you write in that model - things will work. We may just add more relaxed runtime execution mode.

The main problem is that in current memory model is not possible to write well reusable common code that works with several threads.

It really depends on the nature of code in question. Reuse concurrency-safe code shall be pretty easy.

<@U7RD7D4JK> It’s definitely possible to write common code that works with multiple threads. Is there a simple example of what you’re trying to do that you can’t?

<@U8NMFHUGJ> For example Observer pattern. When I use Observable I don't wont to worry about that all Observers which adds into Observable created in the same tread. Also I Can't freeze or detach Observer object because it capture link to the Parent object. But without it the Observable can't put Observers from different threads onto same collection. Oops! What should we do in this case? Create separate collection for each thread? And it's just beginning of implementation for subscribing. I'm scare talking about notifying Observers.

Coupled with the fact that the multi-threaded Corroutines have not yet implemented in Kotlin Native, I don't see any normal ways to implement Observer pattern for Kotlin Native.

<@U7RD7D4JK> Have you tried? Give me some code examples. You do need to worry about the context you’re calling from. Where are you adding an Observer that you don’t know the thread context? As for freezing the parent, what parent are you thinking? Assuming something like a mobile app, you’re configuring that observer from the UI, and almost certainly from the UI thread. It’s really not that complicated. You’re going to experience some rethinking of *how* you architect, but it is not true that you can’t build sophisticated architectures. I would also like mt coroutines, but you can build things now without them. Here’s a basic sample. I need to write a blog post about what this is actually doing, but essentially we pass in a lambda that extracts data from sqldelight whenever the db is updated. That can happen in any thread. That gets pushed to the UI, and is transferred to the main thread along the way. The “parent” isn’t frozen. Just the extract lambda. Thinking in terms of native and thread confinement is different, but it’s really not that complex. It’s actually simpler conceptually. Not wanting to worry about thread context is what gets a lot of developers in trouble in the first place. <https://github.com/touchlab/DroidconKotlin/blob/kotlin-1.3.20/sessionize/lib/src/commonMain/kotlin/co/touchlab/sessionize/ScheduleModel.kt#L14>

It’s not important where objects are created, important is the owner of the object at the moment of registration. <https://github.com/JetBrains/kotlin-native/blob/2d882d1b6cb3d475d41b0b36b677aed4f8b323de/samples/objc/src/objcMain/kotlin/Async.kt#L65> solves somewhat similar problem, where we associate mutable object with frozen state and use frozen state to dispatch to mutable object.

<@U8NMFHUGJ>, <@U3SK5B492>, Thank you for the answers. Will study material that you sent.