Serialization of closures and continuations.

[pdvrieze]

When using continuations it may be very valuable to be able to serialize the continuation. A similar issue applies to lamba's/closures.

Both these "types" are however implicitly created. This allows the compiler to control/generate serialization, but this needs to be implemented (probably by still putting a type annotation on the use site for closures). For continuations it would probably be sufficient to make them serializable iff all members are serializable (including primitives).

This clearly requires changes in code generation by the compiler, but would be very worthwhile and provides a robust broadly applicable replacement for Java Serialization (that can also work in other targets - as long as there is a way for the runtime to determine the concrete type to deserialize).

[sandwwraith]

Probably @elizarov can comment better on that

[elizarov]

All of them will have to be explicitly marked as serializable and assigned some stable serial name. The compiler will have to check that all the state they capture from the outer context is serializable and, for continuations, that the saved state at each suspension point is serializable.

Now, for lambdas that seems to be all. Lambdas are very much like classes. The difference is that the list of what they capture is implicit. The story is more complicated with coroutines, since they have context and their context is usually tied to the "outside world" that is not serializable. I frankly don't know what to do about it in a generic and useful way.

[ghost]

@elizarov is there any piece of code that actually serializes a suspended coroutine and then properly resumes it later? forget java serialization (who uses that anyway?) say with any serialization library of your choice how can this be done? please refer any samples if they exist

[elizarov]

You can read this thread: Kotlin/kotlinx.coroutines#76 There is a link to some working code with Kryo

[pdvrieze]

I actually have a proof of concept library that does this for Android. It uses Kryo (and some nasty hacks) to show the relevance. Serialization (in some form, it could be kotlinx.serialization, or driven by some annotation) is necessary to allow callbacks to work correctly for events that may trigger activity "freezing". An example is startActivityForResult that may launch an activity to get the result (say take a photo). Using callbacks or coroutines makes it much easier to handle more complex flows of these multi-activity (or dialog) flows. In my case I use it for example for an AccountManager client that needs to do many optional things (download/install the authenticator if missing, create an account if missing, reauthenticate the account if needed, select an account if none configured for this app, get permission to use the account) just when you want to get an url connection to make an authenticated web request.

This works fine with coroutines with the added benefit that the coroutine state makes it very easy to remember the progress and don't retry on every start/resume of the activity. Note that this is not limited to coroutines, regular callback lambda's can also work (but need to be serializable in some way - or parcelable).

@vach Yes my library does this. In android. It does some hacks if you have a context/activity in your capture, and will actually quietly try to use the recreated activity as replacement. Perhaps designing the callback carefully (with activity/context receiver) makes such a thing unneeded.

[efemoney]

@pdvrieze You could use a headless retained Fragment also. I just implemented this for startActivityForResult and it should work well in the most common case: configuration changes.

Downside is that it will (technically) not work for the process death scenario but that's a rarer use case.

[sandwwraith]

This is out-of-scope currently. We may return to this idea in the future if there are enough compelling use cases.