On 3/7/07, Davide Libenzi <davidel@xmailserver.org> wrote:
Let's do this. How about you throw this way one of the case that would possibly break, and I test it?
Since you make such claims I assume your signalfd() implementation considers a signal delivered once it is reported to an epoll() caller. Right? This is not what you really want, at least not in all cases. A signal might be something you want to react on right away. Unless pthread_kill() is used it is delivered to the _process_ and not a specific thread. But this means if epoll() reports two events to one thread calling epoll() (one of them being a signal) and this thread is then stuck processing the other request, the signal is not handled even though there might be a second or third thread available to receive the signal. Those threads have the same right to receive the signal and the current implementation always looks for the best/fastest way to deliver the signal. This means to me that reporting the signal in epoll() does _not_ mark the signal as handled. Somehow (probably using the signalfd() descriptor) the thread must explicitly request the signal to be delivered. But if you do this the epoll() handling is fantastically racy if the signal is not blocked. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/