4 ms·

The real issue is that people are using threads for things that processes were originally intended for. Having one thread for the UI, one thread for network cod

The real issue is that people are using threads for things that processes were originally intended for. Having one thread for the UI, one thread for network code, one thread for program logic, etc. is actually a mis-use of threads in POSIX-land. POSIX is designed for you to use multiple processes where in Windows you would use multiple threads. This gets you a lot of robust interprocess communication mechanisms and also memory isolation on systems with an MMU. It also had performance implications on the state of the art hardware at the time, which is why threads were invented. And finally it requires you to expand your usage of the operating system. Being multi-process would solve the issues with a process-global signal handler because there would no longer be a question of which thread generated the signal.

quotemstr 8y ago
It's much more feasible to fix the signals API to work well in a multithreaded world than to roll back the clock to the 1980s and get people to stop using threads.
rocqua 8y ago
This seems like an ivory tower argument, people shouldn't want shared mutable state, so anyone suffering is doing so at their own hand. At the same time, shared mutable state, specifically a fully shared and transparent (ignoring caches) address space is the least effort way to take advantage of multi-core CPUs. Hence, people will be using it. There is essentially no getting around that, and there are even some reasons for wanting it. Being multi-process would solve a lot of issues, but so would settling on a single convention for endianness, rewriting C++ to use unique_ and shared_ptr where applicable, and many other nice to haves. At the end of the day, the easiest road is going to be taken more often. If that happens road is lined with bandits and barely visible traps, that is a problem. No matter how often you tell people not to take that road, and climb a slippery mountain path instead.

quotemstr 8y ago

It's much more feasible to fix the signals API to work well in a multithreaded world than to roll back the clock to the 1980s and get people to stop using threads.

rocqua 8y ago

This seems like an ivory tower argument, people shouldn't want shared mutable state, so anyone suffering is doing so at their own hand. At the same time, shared mutable state, specifically a fully shared and transparent (ignoring caches) address space is the least effort way to take advantage of multi-core CPUs. Hence, people will be using it. There is essentially no getting around that, and there are even some reasons for wanting it. Being multi-process would solve a lot of issues, but so would settling on a single convention for endianness, rewriting C++ to use unique_ and shared_ptr where applicable, and many other nice to haves. At the end of the day, the easiest road is going to be taken more often. If that happens road is lined with bandits and barely visible traps, that is a problem. No matter how often you tell people not to take that road, and climb a slippery mountain path instead.