| |||||||||||||
Kernel events without keventsKernel events without keventsPosted Mar 15, 2007 16:45 UTC (Thu) by vmole (guest, #111)Parent article: Kernel events without kevents
It is worth noting that reading from this file descriptor competes with normal signal delivery for queued signals; there is no way to predict whether the signal will be delivered in the usual way or will be read from the file descriptor. This situation can be avoided by using sigprocmask() to block normal delivery of the signal(s) of interest. Oh, good, another set of racy signal functions. If I call signalfd() before I call sigprocmask(), there's a period where signals can be delivered either way. If I call sigprocmask() first, am I guaranteed that the masked signals will queued to the signal fd when I get around to creating it? This mess is why sigaction(2) was invented, to allow you set both signal of interest and signals to mask in one operation. Is there any reason why you'd want signals delivered both ways? If not, then why doesn't signalfd() automatically mask the signals in its arguments?
(Log in to post comments)
Kernel events without kevents Posted Mar 17, 2007 0:41 UTC (Sat) by giraffedata (subscriber, #1954) [Link] If I call sigprocmask() first, am I guaranteed that the masked signals will queued to the signal fd when I get around to creating it? I haven't seen the implementation, but that would be the most natural way. I don't think signals are queued to a fd at all; I think read of the fd checks for and receives pending signals, in spite of any mask (so poll checks for pending signals). And assuming it's documented with those words, there's not much room for confusion. This mess is why sigaction(2) was invented, to allow you to set both signal of interest and signals to mask in one operation. How does it do that? I don't think sigaction modifies the signal mask. And you don't need it to. Where would it be useful? However, I agree that there is no practical application of signals arbitrarily being delivered traditionally or to an fd, so except that it's extra code, it would be sensible to have signalfd() automatically block the signal class.
Kernel events without kevents Posted Mar 17, 2007 17:19 UTC (Sat) by vmole (guest, #111) [Link] How does it do that? I don't think sigaction modifies the signal mask. I misremembered, partially. The sa_mask member of the structure just blocks signals during delivery of the desired signal, not all the time. (Before sigaction(2), you had to try and call sigprocmask(2) from inside your signal handler to get this affect, which was completely unreliable.) This kind of blocking isn't necessary with signalfd because (duh!) the signals aren't delivered asynchronously.
|
|||||||||||||