Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Cooperative multitasking is much easier to implement and administer than preemptive multitasking, and always has been. But there are cases where it isn't good enough, and if you hit those then you need a system that can do preemptive multitasking gracefully - which often means you end up with just as much complexity as if you'd used preemptive multitasking from the start, but with the complex parts being less well-tested.


>"But there are cases where it isn't good enough, and if you hit those then you need a system that can do preemptive multitasking gracefully ..."

What are some of those use cases where userland threads are no longer good enough? In what areas do they fall short?


Essentially any time you have to run something that's not completely trusted to not block a thread - which could be user-supplied code (or "code" - matching a regex is unsafe in most implementations, rendering PostScript is famously Turing-complete) or just a third-party dependency.

At my first job we had a prototype that performed 2x faster (on average) by using Go-style async, but we couldn't trust our libraries enough to eliminate bugs from blocking dispatcher threads. So we stuck with traditional multithreading.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: