Erik
04/23/2021, 2:41 PM@Synchronized fun foo()
that now is being refactored to be @Synchronized suspend fun foo()
(ℹ️ this is kotlin.jvm.Synchronized
). The synchronisation is still needed if I don't know the context in which this will be called, right? Is there a way to also get rid of the synchronisation? Can I change to a single threaded executor to ensure calls to this function happen sequentially? Or would I need a mutex? Or is it fine as-is? I'm asking because @Synchronized suspend fun foo()
looks a bit non-coroutinesque to me.mkrussel
04/23/2021, 2:52 PMthis
be your lock. Also any other code in the class will need to use the mutex if they were synchronized before. They will then need to be suspended
.
The making access to it single threaded is a good option if possible.
Other option is try to make it not deal with shared state. Trying to create a more functional programming style solution. Send immutable input and get immutable output.
What solution works best depends on the problem being solved.ephemient
04/23/2021, 2:58 PM@kotlin.jvm.Synchronized
doesn't work on suspend fun
- it wouldn't make sense to, as that flags the JVM to take a monitor with the function entry and exit, but as far as the JVM is concerned a suspend fun
enters and exits at every suspend pointErik
04/23/2021, 3:01 PMwithContext
block?ephemient
04/23/2021, 4:14 PMErik
04/23/2021, 4:16 PMephemient
04/23/2021, 4:16 PMErik
04/23/2021, 4:17 PM