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.
