Kotlin Native new memory model

Help
, ,
1

Hello, could you please tell me if it is planned to switch to a new memory model, which is actively promoted in kotlin native? Is it possible now to use a new memory model with the current Apollo implementation?
And another question about current MM: I would like to implement 2 types of dispatchers via expect actual: Main, Background. With the implementation of Background: Dispatcher.Main (IOS) and Background: Dispatcher.IO (Android), so that at least for Android to take all the execution into the background, can there be problems with this?

2

Hi :wave: !

Hello, could you please tell me if it is planned to switch to a new memory model, which is actively promoted in kotlin native?

It definitely is. Any help is welcome there so if you have ideas what to do, feel free to open an issue on Github and we can move the discussion there.

so that at least for Android to take all the execution into the background, can there be problems with this

I think this is fine but you shouldn’t need any of that really. The runtime already offloads all the operations to a background thread (see the design docs for more in-depths details). This is what the MortyComposeKMM project is using for an example. The only limitation at the moment is that you have to call ApolloCall.execute() from the main thread on iOS but that doesn’t mean the underlying network request is done on the main thread. Quite on the contrary, all the hard work is offloaded to background threads.

I hope this helps!
Happy Kotlin!

1 Like
3

Hello!
@mbonnin How do you think if it is possible to use Dispatchers.Unconfined in requestedDispatcher with new memory model with two Dispatchers, so to make configuration outside of the ApolloClient using withContext, or it will not have any effect and will cause conflicts?

4

requestedDispatcher does nothing on native so whatever value you set there will not be used.

The current threading model is:

  • Use NSUrlSession for network
  • Use a worker thread for the cache
  • Use a worker thread for parsing

Usually, this works well and changing the dispatcher shouldn’t be required. Can you share more context about what you’re trying to do? Maybe there’s another solution.

5

Thank you for detailed information!
I’m just wondered about using new memory model, cause it greatly simplifies multithreaded work.
The fact is that I would like to use multithreading not only at the network level, but also for the database, as well as, if possible, for basic entities, for example, for ViewModels. For example, Realm Kotlin SDK supposed to be used with new memory model by disabling internal freezing to accomodate the new freeze transparency for Coroutine 1.6.0. Is it possible now to try using Apollo with new memory model the same way or or it obviously won’t work and it’s worth working with the current memory model for now?

6

I see. Thanks for providing the details :pray:. I haven’t tried it yet but I think there is a good chance you can use the current version with the new memory model by disabling the kotlin.native.binary.freezing gradle property:

kotlin.native.binary.freezing=disabled

(See kotlin/NEW_MM.md at master · JetBrains/kotlin · GitHub for more details)

This will make all freeze a no-op. I’m not 100% sure about the ensureNeverFrozen(). I’d expect it to become a no-op too but if it’s not working, please send us the exception/error and we’ll look into making this work.

1 Like
7

Thank you for suggestion, i will try to use with disabling freezing and will come with feedback)

1 Like