2 ms·
It's ideal in the sense that you don't need to block to wait and you can avoid context switches. But obviously that means abandoning some common patterns.
by jayd16 5y ago
It's ideal in the sense that you don't need to block to wait and you can avoid context switches. But obviously that means abandoning some common patterns.
- colanderman 5y ago"Common patterns" including, running more than one application on a system. I've worked on several thread-per-core systems, including embedded systems in which each thread owns a core and does not make system calls or context switch. You can do that, and it's ideal performance-wise, but it does not apply to multi-process systems -- how else are they to coordinate workflows, than through kernel-visible concurrency constructs: i.e., threads? In language implementations with built-in user-mode schedulers like Go and Erlang, you get closer to this ideal for, as they will spin up a thread per core for CPU-intensive workloads. But even there, blocking system calls are still the norm (at least with Linux, which is only very recently moving toward a generic async system call system, with io_uring), requiring many more threads per core to saturate I/O workloads. And that still doesn't address the multi-process coordination problem.
- jayd16 5y agoAll perfectly valid but I think you're letting perfect be the enemy of good here. Even if your app can be preempted, green threading is still useful.
- colanderman 5y agoI don't disagree. But green threading doesn't address the OP's issue of "too many threads": a process using green threads needs to spawn one thread per CPU if it plans to use the CPU's full power. On say, a 16-core system like the OP's, you're back to 16 threads per process -- on average, more than the OP was complaining about (15).