4 ms·

> signals don't make sense for many of the things they're used for Wut? They're literally the only way to do non-cooperative preemption in userspace. (You can'

> signals don't make sense for many of the things they're used for Wut? They're literally the only way to do non-cooperative preemption in userspace. (You can't do that on Windows without a custom kernel driver BTW.) Meanwhile, if you don't need non-cooperative preemption then don't use fucking signals. Use POSIX shared memory and a pthread mutex. Or use sockets. Whatever. It isn't the fault of POSIX when someone chooses the wrong tool for the job. That's like complaining that the local hardware store does things wrong because you went and bought a jackhammer when what you really needed was a sledgehammer.

Jasper_ 5y ago
You often need to use signals, unfortunately, and they stink. The only way to spawn multiple processes and being told when each of them die is SIGCHLD. I mean, I suppose you could spawn N threads and call waitpid on each one but it would be so much lovelier if you could poll on an fd to know when a child dies. Maybe pidfd now provides that, I hope it does. Windows has it right with WaitOnMultipleObjects supporting mutexes, child process deaths, socket and IO reads and timeouts all in the same interface. Even the BSDs have kqueue now. Only Linux is stuck with the alternatives.
- d110af5ccf 5y ago
  Well fair enough, I stand corrected about "misuse" of signals in certain cases. Nonetheless, non-cooperative preemption is a useful (though oft maligned) tool. The things you describe aren't actually problems with signals but rather other APIs that force you to use them. I'm curious. While it does add a (very small) bit of complexity, can you not just spawn a single sacrificial thread for receiving SIGCHLD and set dispositions accordingly? Then just use standard concurrency primitives to communicate with that thread in whatever way you'd like.
- bcrl 5y ago
  Linux has signalfd(): use it! Avoiding the nightmare of having random syscalls interrupted that is impossible to test and almost always results in failures in production. If you can't use signalfd(), spawn all your processes / threads from a thread that does nothing other than handle SIGCHLD. I've been through the hell of doing it other ways, and it is hell to get correct on a codebase with more than a couple of developers on it, as very few developers remember to think about the consequences of a signal being received during every single syscall or library call.

Jasper_ 5y ago

You often need to use signals, unfortunately, and they stink. The only way to spawn multiple processes and being told when each of them die is SIGCHLD. I mean, I suppose you could spawn N threads and call waitpid on each one but it would be so much lovelier if you could poll on an fd to know when a child dies. Maybe pidfd now provides that, I hope it does. Windows has it right with WaitOnMultipleObjects supporting mutexes, child process deaths, socket and IO reads and timeouts all in the same interface. Even the BSDs have kqueue now. Only Linux is stuck with the alternatives.

d110af5ccf 5y ago
Well fair enough, I stand corrected about "misuse" of signals in certain cases. Nonetheless, non-cooperative preemption is a useful (though oft maligned) tool. The things you describe aren't actually problems with signals but rather other APIs that force you to use them. I'm curious. While it does add a (very small) bit of complexity, can you not just spawn a single sacrificial thread for receiving SIGCHLD and set dispositions accordingly? Then just use standard concurrency primitives to communicate with that thread in whatever way you'd like.
bcrl 5y ago
Linux has signalfd(): use it! Avoiding the nightmare of having random syscalls interrupted that is impossible to test and almost always results in failures in production. If you can't use signalfd(), spawn all your processes / threads from a thread that does nothing other than handle SIGCHLD. I've been through the hell of doing it other ways, and it is hell to get correct on a codebase with more than a couple of developers on it, as very few developers remember to think about the consequences of a signal being received during every single syscall or library call.