Re: [patch 1/4] signalfd v1 - signalfd core ...

[Davide Libenzi <davidel@xmailserver.org>]

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