On 05/23, David Laight wrote:
From: Oleg Nesterov
On 05/23, David Laight wrote:
I'm confused...
Me too. To clarify, the current code is obviously buggy, pselect/whatever shouldn't return 0 (or anything else) if it was interrupted and we are going to deliver the signal.
If it was interrupted the return value has to be EINTR.
Yes, and this is what we need to fix.
Whether any signal handlers are called is a separate matter.
Not really... because in this case we know that the signal will be delivered,
Not sure I understand... OK, suppose that you do
block-all-signals; ret = pselect(..., sigmask(SIG_URG));
if it returns success/timeout then the handler for SIG_URG should not be called?
Ugg... Posix probably allows the signal handler be called at the point the event happens rather than being deferred until the system call completes. Queueing up the signal handler to be run at a later time (syscall exit) certainly makes sense. Definitely safest to call the signal handler even if success/timeout is returned.
Why?
pselect() exists to stop the entry race, not the exit one.
pselect() has to block SIG_URG again before it returns to user-mode, right?
Suppose pselect() finds a ready fd, and this races with SIG_URG.
Why do you think the handler should run?
What if SIG_URG comes right after pselect() blocks SIG_URG again? I mean, how this differs the case when it comes before, but a ready fd was already found?
Oleg.