Davide Libenzi wrote:
quoted text
> 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.

quoted text
>  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?

quoted text
> 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?


    J
-
unsubscribe notice
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/