Date:	Wed, 7 Mar 2007 13:35:25 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists