Messages in this thread | | | Date | Wed, 7 Mar 2007 14:10:47 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [patch 1/4] signalfd v1 - signalfd core ... |
| |
On Wed, 7 Mar 2007, Ulrich Drepper wrote:
> On 3/7/07, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > 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. > > > > .. but maybe with more code and lots of confusion. I'm still unclear on > > any upsides here. > > > > Choice is good, but only if it's *useful* choice. > > Not only that. If you don't force that the signal is blocked when > using signalfd() you are bound to run into problems. For the same > reason is it required to have signals blocked when you use sigwait() > etc. Don't try to innovate here, I guarantee you it's going to break > something somewhere.
Let's do this. How about you throw this way one of the case that would possibly break, and I test it? Queues are separeted, so if you have a signal hitting you while in signalfd_dequeue, either the signal is not for your set (and you'd get an EINTR ATM), or it is for your set too, and signalfd_dequeue will return with it. But again, I'd love to have some insides about possible breakages so that I can make test cases for them.
- 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/
| |