4 ms·
Since at least Windows 3.1 we all know that cooperative multitasking is a bad idea. But we see a lot of developers use it, even Rust developers who should know
by amelius 1mo ago
Since at least Windows 3.1 we all know that cooperative multitasking is a bad idea. But we see a lot of developers use it, even Rust developers who should know better.
- pjmlp 1mo agoIt predates Windows 3.1.
- odo1242 1mo agoCooperative multitasking isn’t universally a bad idea (in fact, Rust supports it)
- econ 1mo agoI can't think of a better way to make simple things billions of times slower than they should be.
- odo1242 1mo agoI'm just going to borrow a sibling comment: > afiori: JavaScript's execution model uses cooperative concurrency to avoid a tons of data races, preemptive non-parallel concurrency would make all web development incredibly harder
- Dylan16807 1mo ago> I can't think of a better way to make simple things billions of times slower than they should be. How's it going to do that? What's so bad about it? Especially in the multi-core era which lets multiple programs run at the same time the way that multiple pages can run javascript at the same time. The lack of preemption is only within a single page/program. During periods of time where no single chunk of code runs for more than a millisecond, cooperative multitasking should have the exact same performance as preemptive multitasking. And even when single chunks of code do run for that long, if that code wasn't properly isolated then preemption doesn't save you from lag. So the difference only shows up when you have chunks of code that keep running way too long, that are also inside of properly isolated threads/callbacks, and on web those threads/callbacks are not inside web workers. Is that a common situation?
- deleted 1mo ago[deleted]
- amelius 1mo agoYou are saying it as if there is some logical consequence.
- afiori 1mo agoJavaScript's execution model uses cooperative concurrency to avoid a tons of data races, preemptive non-parallel concurrency would make all web development incredibly harder
- amelius 1mo agoYes, I was talking from a performance/UX standpoint. Of course, doing everything in one thread most of the time makes everything easier, because you're using the thread as the lock, so to speak. But using locks is bad for performance and latency and thus UX.
- afiori 1mo ago> But using locks is bad for performance and latency and thus UX. yeah but this way you have only one lock, with free threads or preemptive multitasking you have to have them sprinkled into every data structure each with its potential for deadlock and livelocks. Also look at single core focused systems like spacetimedb, sometimes if a workload is not embarrassingly parallelizable multithreading can make things slower. JS needs some way to more easily push things off the main render thread, but i think that there is no easy solution for it. (maybe a model like iirc clojure had where "threads" would automatically rollback and retry in case a data race was detected could work to handle off-threads tasks in js, but it is a quite far off solution)