Messages in this thread | | | Date | Wed, 7 Mar 2007 13:35:25 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [patch 1/4] signalfd v1 - signalfd core ... |
| |
On Wed, 7 Mar 2007, Jeremy Fitzhardinge wrote:
> Davide Libenzi wrote: > > If you think a signal as a generic event source, than you see how more > > instances can attach to it and receive them. > > You can have multiple signalfd with whatever sigmasks, even intersecting. > > You can pass the fd around, w/out the fear that a standard signal delivery > > would race with you on dequeue_signal (making you block after you got a > > POLLIN). > Well, I think using both this mechanism and normal signal delivery would > be pretty much insane. But if you do, then the only sane way to use the > interface is if each signal is delivered once - and only once - by > whatever mechanism (otherwise how would you be able to distinguish > between the same signal duplicated vs two signals which look very > similar?). If you're really worried about losing a signal between poll > and read you can always make the fd nonblocking.
You have the *choice* to do that:
1) You want standard delivery only:
- Just dont use signalfd
2) you want signalfd only:
- Do a sigprocmask(SIG_BLOCK) of the same mask you pass to signalfd
If you want both, you can have it. Race free.
> > You can have both standard and file based devliery, or you can > > not. Up to you. If you don't want to, you block them, otherwise you > > don't. It's flexible, and the code is like 20 lines more, and race-free. > > > > OK, but if you allow the kernel to duplicate along different delivery > paths, usermode pretty much has to go to the effort of making sure > there's only one delivery path in order to keep track of how many > signals really appeared. > > The only way to make duplication sane is to guarantee that if a signal > path *can* deliver a signal, it *will* deliver the signal, so that > usermode has some chance of correlating queued signals along each path. > > But if you do that, then you end up with bad results. If you have a > signal blocked, then it means you're obligated to keep the signal queued > forever in case the signal gets unblocked, even if usermode already got > it via a signalfd and has no intention of ever unblocking the signal. > Similarly with a signalfd that never gets read. And if you fill the > pending signal queue, do you start dropping signals?
In the next patch set (v2), if a GFP_ATOMIC slab alloc fails in allocate a queue item, I incrememt a lost_sigs variable in the context, and poll(2) will return POLLERR.
> > Since the siginfo needed to be delivered too, at that point doing it over > > a read(2) would have messed up things [1], so I added a new syscall: > > > > int signalfd_dequeue(int fd, siginfo_t *info, long timeo); > > > > And the compat_ counter-part. > > > > > > > > [1] I thought about having a compat-free siginfo to be pulled from > > read(2), but that resulted to be messy, while we already have code to > > ship siginfos to userspace. > > > > Hm. Yeah, that's tough. If you have a 32-bit and 64-bit process > reading from the same signalfd source, would you expect them to return > the same format or different?
The signalfd_dequeue() has a compat layer that uses "struct compat_siginfo".
- Davide
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |