Slackbot
06/10/2021, 11:49 AMCLOVIS
06/10/2021, 12:07 PMErik
06/10/2021, 12:34 PM<http://Dispatchers.IO|Dispatchers.IO>
does that with a default maximum size of 64 threads (https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-dispatchers/-i-o.html)Ulrik Rasmussen
06/10/2021, 12:51 PMwithContext(<http://Dispatchers.IO|Dispatchers.IO>) { ... }
. This will allow your single thread pool to continue working while the operation is suspended on the IO
dispatcher.Erik
06/10/2021, 1:45 PMCLOVIS
06/10/2021, 7:08 PMErik
06/10/2021, 7:51 PMCLOVIS
06/10/2021, 8:46 PMErik
06/11/2021, 6:28 AMLooper
. By default that's the main thread only, which invites doing database stuff from UI classes. Yes, I'm talking years back when these kinds of things happened. Now it's 2021 and that's the legacy I'm trying to modernize.Ulrik Rasmussen
06/11/2021, 6:32 AMwithContext(yourSingleThreadedDispatcher) { .. }
instead of <http://Dispatchers.IO|Dispatchers.IO>
? It sounds strange, thoughErik
06/11/2021, 6:36 AMCLOVIS
06/11/2021, 7:28 AMErik
06/11/2021, 8:09 AMperson.name
I must know the thread I must do that on. 🤦♂️
It's like the opposite of the 'shared mutable state' problem. It's unshared mutable state. As in: unshareable. And mutable from multiple threads. That mutability is what I can confine to one thread, but that doesn't give me the freedom to read from any thread. I just cannot pass around instances without also knowing the single thread to CRUD on.
Wrapping every CRUD operation in a singleton single threaded context might be possible, but that sounds like horrible design.CLOVIS
06/11/2021, 8:34 AMErik
06/13/2021, 6:19 AM