Signalfd is useless
ldpreload.com
Signalfd is useless
1–10 of 44 posts
Re: Signalfd is useless
#2Money quote seems to be:
> So you have to be very careful to reset any masked signals before starting a child process
I don't see what this has to do with signalfd. That statement is true generically. Non-default Unix signal handling and subprocess management have never cooperated cleanly. The point to signalfd is to provide a simpler mechanism to integrate signals (which are a legacy API in almost all cases) with existing synchronization and event handling architectures, not to magically make them not suck.
Re: Signalfd is useless
#3Money quote seems to be: > So you have to be very careful to reset any masked signals before starting a child process I don't see what this has to do with signalfd. That statement is true generically. Non-default Unix signal handling and subprocess management have never cooperated cleanly. The point to signalfd is to provide a simpler mechanism to integrate signals (which are a legacy API in almost all cases) with ex…
I am at a loss as to how you decided that was the "money quote". I saw it as an incidental aside as long as he was in the area, in a large post about signalfd, as evidenced by the, you know, 22 instances of the term "signalfd", including one in the title.
Re: Signalfd is useless
#4Money quote seems to be: > So you have to be very careful to reset any masked signals before starting a child process I don't see what this has to do with signalfd. That statement is true generically. Non-default Unix signal handling and subprocess management have never cooperated cleanly. The point to signalfd is to provide a simpler mechanism to integrate signals (which are a legacy API in almost all cases) with ex…
Yup. A lot of people, myself included, were under the impression that signalfd takes over from the normal signal-handling pathway: it doesn't.
It's particularly bad because the only way to get notified on a child exiting, in an event-handling architecture, is to wait for SIGCHLD notifications. (You can't call wait/waitpid because that's blocking; at best you can call it in a separate thread.) So even if all you're trying to do is write a program that runs a handful of children asynchronously, you have to incorporate signals into your architecture. And signalfd taunts you by providing siginfo with each notification, so you think you know which child exited -- but in fact, those siginfos could have coalesced, so this data is useless.
A friend claimed to me that siginfo is only useful for so-called synchronous signals (SIGSEGV, SIGILL, etc. -- stuff that you can't handle in an event loop anyway), which I'm inclined to believe, the more I think about it. So there's no reason for signalfd to have included siginfo.
Re: Signalfd is useless
#5Money quote seems to be: > So you have to be very careful to reset any masked signals before starting a child process I don't see what this has to do with signalfd. That statement is true generically. Non-default Unix signal handling and subprocess management have never cooperated cleanly. The point to signalfd is to provide a simpler mechanism to integrate signals (which are a legacy API in almost all cases) with ex…
Yup. A lot of people, myself included, were under the impression that signalfd takes over from the normal signal-handling pathway: it doesn't. It's particularly bad because the only way to get notified on a child exiting, in an event-handling architecture, is to wait for SIGCHLD notifications. (You can't call wait/waitpid because that's blocking; at best you can call it in a separate thread.) So even if all you're tr…
Both wait() and waitpid() have a non-blocking mode (WNOHANG). So use SIGCHLD to decide when to check the status of the child processes, and waitpid() to actually do it.
Re: Signalfd is useless
#6I've used signalfd before and consider it an improvement over normal signal-handling. Signal coalescing happens regardless of signalfd.
The only major thing you have to remember when using signalfd is to mask the signals you want to only receive via signalfd and then unmask these signals in any child processes before calling exec*() functions.
Re: Signalfd is useless
#7Question from someone not knowing much about low-level programming and dealing with signals:
If signals are so problematic, why rely on them? Is the functionality useful for other things other than dealing with 'emergencies'?
One thing I can see that is useful, is that it allows a program to gracefully deal with a kill, but many applications seem to have a 'graceful stop' mechanism that doesn't need signals.
Re: Signalfd is useless
#8Money quote seems to be: > So you have to be very careful to reset any masked signals before starting a child process I don't see what this has to do with signalfd. That statement is true generically. Non-default Unix signal handling and subprocess management have never cooperated cleanly. The point to signalfd is to provide a simpler mechanism to integrate signals (which are a legacy API in almost all cases) with ex…
Yup. A lot of people, myself included, were under the impression that signalfd takes over from the normal signal-handling pathway: it doesn't. It's particularly bad because the only way to get notified on a child exiting, in an event-handling architecture, is to wait for SIGCHLD notifications. (You can't call wait/waitpid because that's blocking; at best you can call it in a separate thread.) So even if all you're tr…
There are plans for CLONE_FD which allows listening to child process exits via file descriptors: http://lwn.net/Articles/638613/
Re: Signalfd is useless
#9Question from someone not knowing much about low-level programming and dealing with signals: If signals are so problematic, why rely on them? Is the functionality useful for other things other than dealing with 'emergencies'? One thing I can see that is useful, is that it allows a program to gracefully deal with a kill, but many applications seem to have a 'graceful stop' mechanism that doesn't need signals.
A lot of functionality is only available via signals. For instance, there's no way other than SIGCHLD to be asynchronously notified when a process exits (unless you want to dedicate a thread to running wait()). There's no way other than SIGWINCH to be notified when your terminal gets resized.
You could certainly imagine some kernel extensions that take all of this useful functionality and make it available in ways other than signals, leaving just signals for things you have to deal with immediately like SIGSEGV (so you can print a nice error message before quitting), but they don't exist yet. I imagine some of the intent behind signalfd was to do this all at once for all signals, but it didn't quite work.
Re: Signalfd is useless
#10Money quote seems to be: > So you have to be very careful to reset any masked signals before starting a child process I don't see what this has to do with signalfd. That statement is true generically. Non-default Unix signal handling and subprocess management have never cooperated cleanly. The point to signalfd is to provide a simpler mechanism to integrate signals (which are a legacy API in almost all cases) with ex…
Yup. A lot of people, myself included, were under the impression that signalfd takes over from the normal signal-handling pathway: it doesn't. It's particularly bad because the only way to get notified on a child exiting, in an event-handling architecture, is to wait for SIGCHLD notifications. (You can't call wait/waitpid because that's blocking; at best you can call it in a separate thread.) So even if all you're tr…
Thats why kqueue on the BSDs is nicer as it can listen for children. Plus process descriptors for children also make this easier, Linux should get these with the capsicum port eventually.