Erik
03/01/2021, 2:11 PMCoroutineScope.launch(<http://Dispatchers.IO|Dispatchers.IO>) { action() }
(not literally, but that's what it comes down to). If you create a lot of action {}
actions quickly, or if your system is slow, then these launched coroutines aren't necessarily run in order. Remember: launching is fire-and-forget. You don't know when the coroutine is actually run!
So, is my code just an example of bad practice? Or is my code an example of a UniFlow running actions in an unordered fashion, and is that a bug?actor
in the uniflow internals should ensure processing of actions in the order they are sent to it, no matter how fast or slow the actions run. However, my original bug still stands: UniFlow uses launch
to ultimately send actions to the actor, which may cause actions going out of orderarnaud.giuliani
03/01/2021, 4:58 PMUniFlow usesOk, interesting 🤔to ultimately send actions to the actor, which may cause actions going out of orderlaunch
Erik
03/01/2021, 5:07 PMarnaud.giuliani
03/02/2021, 9:00 AMlaunch
but just a withContext
to execute directly the functionErik
03/08/2021, 12:46 PMlaunch
is the cause: https://github.com/uniflow-kt/uniflow-kt/blob/08b6c921a058605de27463a66f17c1b6b6ef7539/uniflow-core/src/main/kotlin/io/uniflow/core/flow/ActionDispatcher.kt#L31
It should be a withContext
(or no context switch at all)arnaud.giuliani
03/08/2021, 1:45 PMlaunchOnMain
Erik
03/09/2021, 10:07 AMactor.send
which is a suspend fun
offer
should be used instead. The buffer is there for a reason: we should limit concurrency in some way, because it's not free. When the action buffer is full, we can either suspend, ignore the action, or worse: throw.offer
, or use a different scope/context. runBlocking
would work, but that could block the user, so not an optionarnaud.giuliani
03/09/2021, 10:45 AMoffer
could block then ... but we avoid the coroutines lunch just for offeringErik
03/09/2021, 10:49 AMarnaud.giuliani
03/09/2021, 10:53 AMErik
03/09/2021, 11:43 AMarnaud.giuliani
03/09/2021, 3:22 PM