4 ms·

Honestly, this reads like a thorough indictment of signals in user space. * Signal handlers are process global * Signal handlers need to be re-entrant safe Re

by rocqua 8y ago

Honestly, this reads like a thorough indictment of signals in user space. * Signal handlers are process global * Signal handlers need to be re-entrant safe Re-entrancy is painful but can be done, but process-global signal handlers means that pulling in a totally unrelated library can break your code. Moreover, it makes the combined use of certain libraries straight-up impossible. Similarly, it means that the use of library precludes you from using certain features. Combined, this means that the use of signal handlers is simply toxic. Which makes them an anti-feature. It feels to me like having the restrictions of kernel-space, with all of the downsides of user-space. Are there any plans in linux to replace signals?

qiqitori 8y ago
Normal libraries should never register signal handlers. Google Breakpad is a crash-reporting system and as such requires signal handling to function. Also since we're on the topic, here's a nice vulnerability caused by bad signal handling: https://news.ycombinator.com/item?id=16753013 https://news.ycombinator.com/item?id=16753013 Pretty sure there are no plans to replace signals, but maybe there are libraries that make signal handling easier?
- loeg 8y ago
  > Pretty sure there are no plans to replace signals, but maybe there are libraries that make signal handling easier? Non-portable, but sigprocmask() SIG_BLOCK plus signalfd() (Linux) or kqueue() EVFILT_SIGNAL (BSDs). Neither is a good solution for handling mmap SIGBUSes, but they're generally good for handling most signals (USRn, TERM, HUP, CHLD, etc) more similarly to other kinds of events.
  - wahern 8y ago
    signalfd does NOT work the same as kqueue EVFILT_SIGNAL. On Linux signalfd basically behaves the same as installing a signal handler--only a single signalfd object will receive a signal, so whether installing a signal handler or a signalfd listener you're changing behavior globally. It's even messier than that, because signalfd only works if there are no other signal handlers installed. By contrast, with kqueue all EVFILT_SIGNAL listeners will be notified of a signal, even if the signal was also delivered to a handler. Big difference. This is one among many reasons why Linux's event syscalls are widely considered inferior to BSD kqueue. It's ridiculous considering that kqueue not only predated epoll by several years and signalfd by nearly a decade, with ample use cases, it was well documented in a paper that described the rationale for all the semantics. Somehow the authors of epoll, signalfd, etc couldn't even bothered do to basic research; they just spitballed semantics without having much real-world experience about what was needed and most useful.
- rocqua 8y ago
  > Normal libraries should never register signal handlers. That statement alone should be enough to re-examine a feature. Code composition is a rather nice thing to have, making that very complicated is not a good thing.
jschwartzi 8y ago
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.
beat 8y 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 8y ago
  A 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 8y ago
    Signals play nice with threads. It's sloppy thread programming that doesn't play nice with signals.
    - rocqua 8y ago
      Consider 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 8y ago
        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.
theoh 8y ago
Previously: https://news.ycombinator.com/item?id=11899385 https://news.ycombinator.com/item?id=11899385 "I found a paragraph in this article http://www.linusakesson.net/programming/tty/ http://www.linusakesson.net/programming/tty/ very apt at describing what Unix signals are like: In *The Hitchhiker's Guide to the Galaxy*, Douglas Adams mentions an extremely dull planet, inhabited by a bunch of depressed humans and a certain breed of animals with sharp teeth which communicate with the humans by biting them very hard in the thighs. This is strikingly similar to UNIX, in which the kernel communicates with processes by sending paralyzing or deadly signals to them."
quotemstr 8y ago
There's nothing wrong with signals per se. The problem is the signals API. Why do signals handlers need to be process-global? Why do we need to live with global signal handler registration clobbering any previous registration? We can change these things! These problems are all fixable without "replac[ing] signals" as the mechanism. Ultimately, as long as processors have traps (which they will, as long as we have virtual memory) and as long as you want to give userspace to do something in response to these traps other than immediately die (an ability that's tremendously useful) you need some kind of stop-the-thread-that-trapped-and-call-a-callback mechanism, and whatever shape that mechanism takes, it's going to end up looking at least somewhat like signals. Instead of just saying "signals are awful" and burying our heads in the sand, we should talk about what a better signals API should look like. I've already written a detailed proposal that I've linked elsewhere. The real problem here is that the glibc people are completely uninterested in actually improving the signals API. Instead, they've taken the radical, unhelpful, and realistic stance that nobody should be using signals. As long as they think that way, people will keep using sigaction(2), and the world will remain in a half-broken and awful state.
- rocqua 8y ago
  For others [1] is the proposal meant, suggested in HN comment [2] [1] https://www.facebook.com/notes/daniel-colascione/toward-shareable-posix-signals/10157129032641102/ https://www.facebook.com/notes/daniel-colascione/toward-shar... [2] https://news.ycombinator.com/item?id=19806448 https://news.ycombinator.com/item?id=19806448

by rocqua 8y ago

qiqitori 8y ago

Normal libraries should never register signal handlers. Google Breakpad is a crash-reporting system and as such requires signal handling to function. Also since we're on the topic, here's a nice vulnerability caused by bad signal handling: https://news.ycombinator.com/item?id=16753013 https://news.ycombinator.com/item?id=16753013 Pretty sure there are no plans to replace signals, but maybe there are libraries that make signal handling easier?

loeg 8y ago
> Pretty sure there are no plans to replace signals, but maybe there are libraries that make signal handling easier? Non-portable, but sigprocmask() SIG_BLOCK plus signalfd() (Linux) or kqueue() EVFILT_SIGNAL (BSDs). Neither is a good solution for handling mmap SIGBUSes, but they're generally good for handling most signals (USRn, TERM, HUP, CHLD, etc) more similarly to other kinds of events.
- wahern 8y ago
  signalfd does NOT work the same as kqueue EVFILT_SIGNAL. On Linux signalfd basically behaves the same as installing a signal handler--only a single signalfd object will receive a signal, so whether installing a signal handler or a signalfd listener you're changing behavior globally. It's even messier than that, because signalfd only works if there are no other signal handlers installed. By contrast, with kqueue all EVFILT_SIGNAL listeners will be notified of a signal, even if the signal was also delivered to a handler. Big difference. This is one among many reasons why Linux's event syscalls are widely considered inferior to BSD kqueue. It's ridiculous considering that kqueue not only predated epoll by several years and signalfd by nearly a decade, with ample use cases, it was well documented in a paper that described the rationale for all the semantics. Somehow the authors of epoll, signalfd, etc couldn't even bothered do to basic research; they just spitballed semantics without having much real-world experience about what was needed and most useful.
rocqua 8y ago
> Normal libraries should never register signal handlers. That statement alone should be enough to re-examine a feature. Code composition is a rather nice thing to have, making that very complicated is not a good thing.

jschwartzi 8y ago

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.

beat 8y 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 8y ago
A 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 8y ago
  Signals play nice with threads. It's sloppy thread programming that doesn't play nice with signals.
  - rocqua 8y ago
    Consider 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 8y ago
      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.

theoh 8y ago

Previously: https://news.ycombinator.com/item?id=11899385 https://news.ycombinator.com/item?id=11899385 "I found a paragraph in this article http://www.linusakesson.net/programming/tty/ http://www.linusakesson.net/programming/tty/ very apt at describing what Unix signals are like: In *The Hitchhiker's Guide to the Galaxy*, Douglas Adams mentions an extremely dull planet, inhabited by a bunch of depressed humans and a certain breed of animals with sharp teeth which communicate with the humans by biting them very hard in the thighs. This is strikingly similar to UNIX, in which the kernel communicates with processes by sending paralyzing or deadly signals to them."

quotemstr 8y ago

There's nothing wrong with signals per se. The problem is the signals API. Why do signals handlers need to be process-global? Why do we need to live with global signal handler registration clobbering any previous registration? We can change these things! These problems are all fixable without "replac[ing] signals" as the mechanism. Ultimately, as long as processors have traps (which they will, as long as we have virtual memory) and as long as you want to give userspace to do something in response to these traps other than immediately die (an ability that's tremendously useful) you need some kind of stop-the-thread-that-trapped-and-call-a-callback mechanism, and whatever shape that mechanism takes, it's going to end up looking at least somewhat like signals. Instead of just saying "signals are awful" and burying our heads in the sand, we should talk about what a better signals API should look like. I've already written a detailed proposal that I've linked elsewhere. The real problem here is that the glibc people are completely uninterested in actually improving the signals API. Instead, they've taken the radical, unhelpful, and realistic stance that nobody should be using signals. As long as they think that way, people will keep using sigaction(2), and the world will remain in a half-broken and awful state.

rocqua 8y ago
For others [1] is the proposal meant, suggested in HN comment [2] [1] https://www.facebook.com/notes/daniel-colascione/toward-shareable-posix-signals/10157129032641102/ https://www.facebook.com/notes/daniel-colascione/toward-shar... [2] https://news.ycombinator.com/item?id=19806448 https://news.ycombinator.com/item?id=19806448