3 ms·
Signals are fundamental to the unix design. That'd be like "I want a car, but without any wheels, because wheels are often implicated in crashes". Depending on
by beat 7y ago
Signals are fundamental to the unix design. That'd be like "I want a car, but without any wheels, because wheels are often implicated in crashes".
Depending on OS internals within threading is a problem. Libraries that implement their own signal handling are a problem. Trying to get thread-local signal handling behavior when signals are process-global is a problem.
Threads are not a wholesale substitute for processes. Signals work just fine, as long as you plan for ways they can affect your code's behavior.
- rocqua 7y agoA feature that 1. cannot be used if we compose two systems that use it 2. precludes using other mainstream features 3. is an essential part of the interface between userspace and kernelspace is a bad feature. I am not saying we should drop the idea of allowing userspace to respond to things the kernel raises. I am saying we need a way that will allow 1. program composition and 2. play nice with threads. I am not a unix/linux expert, but those requirements seem like they could be met.
- beat 7y agoSignals play nice with threads. It's sloppy thread programming that doesn't play nice with signals.
- rocqua 7y agoConsider the following scenario: Two threads both want to MMAP a file / catch SIGSEGV for different pieces of code. Moreover, these threads come from different modules of a system maintained by different people. All of a sudden, these modules become coupled because we need some system for delegation of signal handlers between them. Or, we need to introduce a custom signal-handler module to deal with our delegation. I would not call that 'playing nice with threads' nor would I call that sloppy thread programming.
- hyc_symas 7y agoYou're really just talking about poor practice in writing signal handlers. The signal API always tells you the previous value of a handler. Your own handlers should remember the previous value and call it if your own handler doesn't fully handle a signal it receives.