3 ms·
Cheap threads are fine if you’re in a server environment, and you need to spin up a large number of short lived parallel jobs. It’s not hugely helpful for a UI
by joe_fishfish 4y ago
Cheap threads are fine if you’re in a server environment, and you need to spin up a large number of short lived parallel jobs.
It’s not hugely helpful for a UI-bound application which occasionally needs to move some work into a background thread to cut down on UI jank.
Kotlin’s suspending function syntax effectively lets you know which operations are going to (potentially) take a while, so you can make sure the UI thread isn’t blocked, and also make sure you’re communicating to the user that something is happening.
- kasperni 4y agoCustom schedulers are coming later with Project Loom. Should be fairly easy to create something where particular threads could have a higher/lower priority.
- nlitened 4y agoIf I understand your point correctly, you say that suspend keyword gives you a hint for which functions are long running, so that you run them in a background thread. I think that’s a very flawed assumption. Some IO operations are pretty fast, like reading a local filesystem, and can be done in the UI thread, while some heavy non-async functions are accidentally O(n^2), and freeze your IO thread. And if you say that “of course you should know what you’re doing”, then I think that suspend syntax just adds extra complexity without much semantic benefit.
- invalidname 4y agoLoom has zero impact on client, sure. But I disagree that async is better for client. It makes it much harder to debug and track issues.