is there a way to perform awaitAny on a collection of jobs i

Question

is there a way to perform awaitAny on a collection of jobs i e wait for first that finishes

louiscad · Answer

< Mikael Alfredsson> Do you want to cancel the other ones

Mikael Alfredsson · Answer

yes first result wins the other ones are not necessary after that

louiscad · Answer

Alright I use this all the time in Android apps especially UI code includes infinite suspending loops that I want to run while the race is ongoing

louiscad · Answer

Check this anchored link <https github com LouisCAD Splitties tree main modules coroutines racing coroutines>

Mikael Alfredsson · Answer

looks nice thanks

louiscad · Answer

And here s the permalink to the code that powers these `raceOf` and `race` + `launchRacer` functions `raceOf` is great for most use cases but if you have a dynamic number of racers or late racers `race` + `launchRacer` is the tool you need <https github com LouisCAD Splitties blob 1936c6c7e445c048077d8b4b7bb1c13b99e0ca0a modules coroutines src commonMain kotlin splitties coroutines Racing kt|https github com LouisCAD Splitties blob 1936c6c7e445c048077d8b4b7bb1c13b99e0ca0 coroutines src commonMain kotlin splitties coroutines Racing kt>

louiscad · Answer

< elizarov> It s been a bunch of times I see folks that need this use case of racing coroutines and cancelling losers Do you think `raceOf` and `race` could make it into the API of kotlinx coroutines in the current form or one close to it EDIT If the answer is yes I ll open an issue and a PR for that

okarm · Answer

< louiscad> ~Could you elaborate how you use `race` in Android applications ~ nevermind I clicked on the link face with rolling eyes

Mikael Alfredsson · Answer

since awaitAny would be orthogonal with awaitAll I would aim for that first not supporting dynamic racers Should be easy to argue for in the API

louiscad · Answer

I don t want my API to win I want the best API to win and stay on the long run without breaking users of kotlinx coroutines and I m unsure it s the best API

louiscad · Answer

I don t like `awaitAny ` because its name makes it that it must not cancel the late ones which is rarely what you want unless you want to waste resources or have bugs

Mikael Alfredsson · Answer

sometimes you don t want to cancel them If you only need the result of one but you still want the sideeffects from the others then cancel is optional

louiscad · Answer

Can you give the example of a real world use case where this would be needed

Mikael Alfredsson · Answer

maybe not the normal usecase but still it would be nice to have that option `awaitAny` could take a parameter on how to handle the rest usecase Send a FCM to all members of the on call support team We are happy to know that atleast one got it but the rest should get it if possible

Mikael Alfredsson · Answer

for saving data over multiple nodes the same can be argued for We want to know that its saved but if it can save to the other ones as well

Mikael Alfredsson · Answer

im dealing with very flaky transmissions at my current position slightly smiling face

louiscad · Answer

I don t think you d want `awaitAny ` for that push notification use case You d want to watch live how many are getting it out of how many so you d get a `Flow` of a ratio and you could just use `first it receivedCount gt 1 `

Mikael Alfredsson · Answer

wouldnt that be completely the same as awaitAny but with flows

louiscad · Answer

Then you are asked to evolve to see the progress and the failure rate and you need to re architect the whole thing sweat smile

louiscad · Answer

But yes `awaitAny ` could do it The thing is that such an easy way to do it IMHO would lead to people often using the wrong tool like using `awaitAny ` in places where they should have used `raceOf` or an equivalent that cancels the late ones

louiscad · Answer

That s why I think it s best to not bring it to kotlinx coroutines in such a form

Mikael Alfredsson · Answer

`awaitAny CANCEL WAITING ` or `awaitAny LEAVE WAITING ` for example

louiscad · Answer

waiting blob thinking fast

Mikael Alfredsson · Answer

maybe not the best naming but I guess you get what I m aimng for

louiscad · Answer

Also I don t like SCREAMING CASE it s distracting and unfair to the rest of the code

louiscad · Answer

Yes I get it I always got what you said I m also thinking about API naming knowing it s know to not be easy sweat smile

louiscad · Answer

One this is that if some code is left uncancelled it should be explicit clear from the name of the method `awaitAny` is explicit actually I just fear it s too easy to use it when you don t factor the late runners Maybe with a required parameter like this `awaitAny cancelOthers = true `

louiscad · Answer

WDYT

Mikael Alfredsson · Answer

Im trying to think about other use cases i e should it be an enum or a flag but right now I can t think of any so a flag that defaults to `cancelOthers` seems reasonable

Mikael Alfredsson · Answer

someone else probably can find a case for `awaitN count = 1 cancelOthers = true ` but I cant find that case now slightly smiling face

louiscad · Answer

I don t think it should have a default value because await any alone doesn t imply cancelling It s like waiting for someone in a store doesn t imply you close the door for others Hence having this default behavior which is still the most common one I believe for async programming would be surprising with the code kinda lying about what s it doing

Mikael Alfredsson · Answer

I like defaults for the most common behaviour but that might be a personal thing

Mikael Alfredsson · Answer

anyway thanks for the `raceOf` code

louiscad · Answer

That s not a personal thing I also like defaults for the most common behavior so long it s not suprising or lying when you factor what s actually written