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.
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.
You'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.
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.