4 ms·

> It's possible to do much better than sigaction(2). I wrote up a detailed proposal for improvement in [1]. Thanks for interesting read. That said, I can see w

> It's possible to do much better than sigaction(2). I wrote up a detailed proposal for improvement in [1]. Thanks for interesting read. That said, I can see why glibc people didn't appreciate the proposal. The first part of article doesn't mention async-signal safety at all. Second part papers over async-signal safety, as if it were a non-issue. There are some dangerous-sounding paragraphs too: > It’s occasionally useful to longjmp out of a signal handler. It’s reasonable to want to return non-locally from a shared signal handler too --- that is, to resume program execution after SIGNAL_CONTINUE_EXECUTION in a different state from the state the program had when we entered the shared signal handler. Since the signal system probably wants to maintain some kind of state to track its progress through its shared signal handler list, a plain longjmp out of a shared signal handler will likely leave the system in an unspecified state. Are you sure, that we should worry about "signal system maintaining some kind of state"? Not about rest of application being in completely unspecified state?!! The article proposes a primitive system for setting signal priorities, but stops at a half-baked solution. There is a mention of banning longjmp, but individual handlers still can bail via SIGNAL_CONTINUE_EXECUTION. What if I want my handler to always run regardless of registration order? The proposal does not offer a way to retrieve a list of already installed handlers, which makes that part of it even worse than existing Posix signal API. The proposed API does not address challenges of using signals in multi-threading programs. The article mentions, that signal handlers can't be reliably unloaded, but proposed API does not address it. Overall the proposed interface brings little to the table, does not work well alongside with existing sigaction() API and creates false illusion, that signal handlers are safe and ok to use. I imagine, that if it had more technical "meat" — more like robust mutexes or FD_CLOEXEC — it would have seen a lot more constructive discussion and less hostility from glibc maintainers.

quotemstr 7y ago
> The first part of article doesn't mention async-signal safety at all. Second part papers over async-signal safety, as if it were a non-issue. If you're writing a signal handler, the signal handler needs to be async-signal-safe. You can't just wave your arms and make the problem of async signal safety disappear, because CPU traps themselves are async-signal-unsafe. Even userfaultfd has to deal with async signal safety issues, since a thread causing a fault can, in principle, be anywhere! > Are you sure, that we should worry about "signal system maintaining some kind of state"? Not about rest of application being in completely unspecified state?!! If your handlers play by the rules and are async-signal-safe, there's no problem. > The article proposes a primitive system for setting signal priorities, but stops at a half-baked solution. What's half-baked about it? > What if I want my handler to always run regardless of registration order? That's a logical nonsense request. What if two components want to their handlers to be the highest priority? > The proposal does not offer a way to retrieve a list of already installed handlers, which makes that part of it even worse than existing Posix signal API. The whole point of the facility is to let different components share a signal without stepping on each other. Why would you need to retrieve the list of handlers? > The proposed API does not address challenges of using signals in multi-threading programs. This claim is too vague to rebut. What specific "challenges" are you talking about? > The article mentions, that signal handlers can't be reliably unloaded, but proposed API does not address it. The proposed API works fine with library unloading: a library can unregister whatever handlers it's installed just before being unloaded (e.g., in a static destructor), and this unregister operation is guaranteed to be safe no matter what the order handlers are unloaded. > Overall the proposed interface brings little to the table It allows multiple components to safely share signals. The objections you've mentioned are based on your misunderstanding my proposal. > does not work well alongside with existing sigaction() Yes it does. The article talks about this interaction specifically. > I imagine, that if it had more technical "meat" The glibc people literally think that nobody should be using signals. That's their objection, not anything you've talked about.
- altfredd 7y ago
  > The glibc people literally think that nobody should be using signals. That's their objection, not anything you've talked about. I don't believe, that everyone holds that opinion. Even if they did, the world does not revolve around Red Hat's team, — there are still kernel mail lists and other venues for discussion. But if proposed improvements aren't well thought-out, would anyone there back them up? In my opinion, async-signal safety in itself is much bigger problem than robust registration of signals. The later is mostly solved by chaining signal handlers, while former is mostly unsolved (and keeps getting worse). Proliferation of new libraries and async-signal unsafe conventions. People keep using printf() in signal handlers. Occurrences of fork() in multi-threaded apps. Still no async-signal safe malloc() (some Googlers tried, but the idea didn't get much traction). And then you come and propose new interface for registering signals handlers, and say that "It’s okay for two functions can be async-signal-unsafe". If your proposed API is async-signal unsafe, how would it deal with signals arriving during dispatch of signal handler list?
  - quotemstr 7y ago
    > But if proposed improvements aren't well thought-out, would anyone there back them up? I think the proposal is thought-out. It's the objections I've seen that suggest a lack of thorough consideration. > the world does not revolve around Red Hat's team The facility I'm describing needs to be in libc to be useful, and for better or worse, if it's not in glibc and isn't something you can use as a raw system call, it might as well not exist. > In my opinion, async-signal safety in itself is much bigger problem than robust registration of signals Async signal safety concerns are inherent in any approach that exposes CPU traps to userspace, since traps occur at instruction granularity. As I've said elsewhere, writing async-signal-safe code isn't that hard if you follow a few basic rules. You can't solve the async signal safety problem, and we shouldn't need an all-singing, all-dancing async-signal-safety-requirement-avoidance system just to improve on the signal API. The alternative to what I'm proposing isn't that everyone abandons signals. The alternative is that everyone keeps using sigaction, which sucks. > The later is mostly solved by chaining signal handlers, No, it isn't. I go into great detail in my note, in which I explain why current solutions to this problem are lacking and describe ways we can do better. > Proliferation of new libraries and async-signal unsafe conventions. People keep using printf() in signal handlers. Occurrences of fork() in multi-threaded apps. Okay, so don't do those things. The problems you're describing all come from people ignorant of safe signal-handler programming practices writing bad code. The problems disappear with education. The problems I'm describing don't disappear with education, since the current signal API imposes unavoidable limitations that even the best code can't work around, even in principle. It's as if we have a car with hand-cranked windows and no brakes and you're annoyed that we would fix the brakes before adding power windows. The brakes are necessary to drive the car properly. Power windows are just an ergonomic feature. > If your proposed API is async-signal unsafe, how would it deal with signals arriving during dispatch of signal handler list? I don't understand this objection. Registration doesn't have to be async-signal-safe. Dispatch must be. There are multiple ways of implementing such a system --- e.g., CAS on a word pointing to a signal control structure.

quotemstr 7y ago

> The first part of article doesn't mention async-signal safety at all. Second part papers over async-signal safety, as if it were a non-issue. If you're writing a signal handler, the signal handler needs to be async-signal-safe. You can't just wave your arms and make the problem of async signal safety disappear, because CPU traps themselves are async-signal-unsafe. Even userfaultfd has to deal with async signal safety issues, since a thread causing a fault can, in principle, be anywhere! > Are you sure, that we should worry about "signal system maintaining some kind of state"? Not about rest of application being in completely unspecified state?!! If your handlers play by the rules and are async-signal-safe, there's no problem. > The article proposes a primitive system for setting signal priorities, but stops at a half-baked solution. What's half-baked about it? > What if I want my handler to always run regardless of registration order? That's a logical nonsense request. What if two components want to their handlers to be the highest priority? > The proposal does not offer a way to retrieve a list of already installed handlers, which makes that part of it even worse than existing Posix signal API. The whole point of the facility is to let different components share a signal without stepping on each other. Why would you need to retrieve the list of handlers? > The proposed API does not address challenges of using signals in multi-threading programs. This claim is too vague to rebut. What specific "challenges" are you talking about? > The article mentions, that signal handlers can't be reliably unloaded, but proposed API does not address it. The proposed API works fine with library unloading: a library can unregister whatever handlers it's installed just before being unloaded (e.g., in a static destructor), and this unregister operation is guaranteed to be safe no matter what the order handlers are unloaded. > Overall the proposed interface brings little to the table It allows multiple components to safely share signals. The objections you've mentioned are based on your misunderstanding my proposal. > does not work well alongside with existing sigaction() Yes it does. The article talks about this interaction specifically. > I imagine, that if it had more technical "meat" The glibc people literally think that nobody should be using signals. That's their objection, not anything you've talked about.

altfredd 7y ago
> The glibc people literally think that nobody should be using signals. That's their objection, not anything you've talked about. I don't believe, that everyone holds that opinion. Even if they did, the world does not revolve around Red Hat's team, — there are still kernel mail lists and other venues for discussion. But if proposed improvements aren't well thought-out, would anyone there back them up? In my opinion, async-signal safety in itself is much bigger problem than robust registration of signals. The later is mostly solved by chaining signal handlers, while former is mostly unsolved (and keeps getting worse). Proliferation of new libraries and async-signal unsafe conventions. People keep using printf() in signal handlers. Occurrences of fork() in multi-threaded apps. Still no async-signal safe malloc() (some Googlers tried, but the idea didn't get much traction). And then you come and propose new interface for registering signals handlers, and say that "It’s okay for two functions can be async-signal-unsafe". If your proposed API is async-signal unsafe, how would it deal with signals arriving during dispatch of signal handler list?
- quotemstr 7y ago
  > But if proposed improvements aren't well thought-out, would anyone there back them up? I think the proposal is thought-out. It's the objections I've seen that suggest a lack of thorough consideration. > the world does not revolve around Red Hat's team The facility I'm describing needs to be in libc to be useful, and for better or worse, if it's not in glibc and isn't something you can use as a raw system call, it might as well not exist. > In my opinion, async-signal safety in itself is much bigger problem than robust registration of signals Async signal safety concerns are inherent in any approach that exposes CPU traps to userspace, since traps occur at instruction granularity. As I've said elsewhere, writing async-signal-safe code isn't that hard if you follow a few basic rules. You can't solve the async signal safety problem, and we shouldn't need an all-singing, all-dancing async-signal-safety-requirement-avoidance system just to improve on the signal API. The alternative to what I'm proposing isn't that everyone abandons signals. The alternative is that everyone keeps using sigaction, which sucks. > The later is mostly solved by chaining signal handlers, No, it isn't. I go into great detail in my note, in which I explain why current solutions to this problem are lacking and describe ways we can do better. > Proliferation of new libraries and async-signal unsafe conventions. People keep using printf() in signal handlers. Occurrences of fork() in multi-threaded apps. Okay, so don't do those things. The problems you're describing all come from people ignorant of safe signal-handler programming practices writing bad code. The problems disappear with education. The problems I'm describing don't disappear with education, since the current signal API imposes unavoidable limitations that even the best code can't work around, even in principle. It's as if we have a car with hand-cranked windows and no brakes and you're annoyed that we would fix the brakes before adding power windows. The brakes are necessary to drive the car properly. Power windows are just an ergonomic feature. > If your proposed API is async-signal unsafe, how would it deal with signals arriving during dispatch of signal handler list? I don't understand this objection. Registration doesn't have to be async-signal-safe. Dispatch must be. There are multiple ways of implementing such a system --- e.g., CAS on a word pointing to a signal control structure.