3 ms·

> 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 writi

> 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 8y 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 8y 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.

altfredd 8y 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 8y 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.