Im still not confident enough with coroutines to know whether im doing it right... thats why i took this example, which im using in a few android projects, to see how others would do it.

How can I do stuff in parallel?

Let's say I have this function:

@Paul Woitaschek uploaded a file: Untitled

And I want to always have 3 mySuspendingTasks running

@Paul Woitaschek I'd say you want a channel (https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md#channels) and then 3 coroutines reading from it.

@gildor commented on @Paul Woitaschek’s file https://kotlinlang.slack.com/files/U0KBF8D7V/F874LC8BF/-.kt:

(0..100).chunked(3).map { tasks ->
            tasks.map {
                async { mySuspendingTask() }
            }.map { defered ->
                job.await()
            }
        }

Hm that's not nice 😛

@gildor commented on @Paul Woitaschek’s file https://kotlinlang.slack.com/files/U0KBF8D7V/F874LC8BF/-.kt: Or

launch

and

job.join()

if you don’t need result

That would wait until each chunk completes right?

Yes

if you want just 3 parallel, just start 1 coroutine for each task + thread pool

Solution with channel also will work

Thanks, I'll try that

I'm looking for an equivalent to this:

@Paul Woitaschek uploaded a file: Untitled

This example might help: https://github.com/Kotlin/kotlinx.coroutines/blob/master/reactive/coroutines-guide-reactive.md#merge

Of course, the story is different if you need results for all those parallel tasks to do something with them. In this case you use

async

and

map

over the results again to retrieve them:

(0..100).map { async { mySuspendingTask() } }.map { it.await() }

You can use Dispatcher with limited ammount of threads for that, like in my example above

… if network requests are sync. For async network request you’ll need a pattern called “worker pool”. There are slides somewhere about it for Go lang. It is easy to translate into Kotlin.

I've been playing around with coroutines in Android the last week. I've actually managed to use them to solve my biggest bugbear - Handling startActivityForResult, and the slightly less annoying handling of dialogs. The upside is that I've managed to make it work correctly. Thanks to Kryo I've even managed to make it survive activity/app restarts. Serialization isn't pretty and there are a number of serialization issues (I've worked around it by custom configuration). Runblocking from its semantics isn't really recoverable (what thread should it be deserialized on?) It does some nasty things with contexts to detect a context/activity and instead of serializing the activity it is passed an activity on deserialization which is put in its place (it's ugly but really works, and it is too easy to implicitly capture an an activity in your lambda's). The code is athttps://github.com/pdvrieze/darwinlib/blob/master/src/main/java/nl/adaptivity/android/coroutines/CoroutineActivity.kt (and related files). It's not very clean yet, but feedback is much appreciated.

don't think that'll work if you turn on the destroy activities debug setting

@kenkyee Actually it does. And was developed mainly with it on. I'll admit it is nasty and must use sun.misc.Unsafe, but it can work. It's a hack but it even works with Activity subclasses captured (although it makes the assumption that the activity is the same one as resuming (in onActivtiyResult)).

@kenkyee I will admit that the serialization stuff is not quite comprehensive (and could do with further checking), but the proof of concept is there. It works through the continuation being serialized into a ByteArrayOutputStream, the bytearray backing it then being stored into a Parcellable (special casing serialization of various types to make it work correctly). To actually make handling the activityResult transparently what happens is that the code will create an invisible fragment that is added to the activity -

startActivtiyForResult

is called on this fragment - fragments will receive the events and are automatically saved with their arguments (the continuation is provided as such an argument with a Parcelable wrapper). There are various ways to break it - Don't capture View objects as I haven't special cased them - activities are sufficient.

ahh...I see..you're saving the activityresult parcelable in your continuation fragment..can't think of why that wouldn't work...

@kenkyee The fragment is responsible for storing the continuation. It is also responsible for resuming it once

onActivityResult

is called. I'm using Kryo with various custom mappings to actually serialize (and harder) deserialize the continuation object. Like I say, the serialization does various things. It special cases the marker objects used by Kotlin in for example SafeContinuation. It also handles Kotlin objects special (refer to the value of INSTANCE, don't load another one). It also rips out all Context objects and on reserialization sets them based on the passed in activity (it could be more robust storing the actual type and verifying on deserialization). If you want to see how it works, the serialization is defined in https://github.com/pdvrieze/darwinlib/blob/master/src/main/java/nl/adaptivity/android/kryo/KryoIO.kt

@pdvrieze That is a great PoC. We plan to improve serializability for coroutines by turning all the magic constants (

UNDEFINED

and

RESUME

) into instance internal enums and make various xxxContinuation classes implement

Serializable

. This will not make the whole serialization story entirely trivial, though, because you’ll still have to carefully rip out and reinstall contexts when serializing/deserializing coroutines.

Whoa,

onActivityResult

with coroutines would be a huge thing!