Messages in this thread | | | Subject | RE: RFC/patch: down_timeout_interruptible() | Date | Sun, 25 Feb 2007 22:37:40 -0800 | From | "Perez-Gonzalez, Inaky" <> |
| |
>From: Arjan van de Ven [mailto:arjan@infradead.org] > >> I gave it a quick try (must admit, not too tested) and it seems that >> the setting of TIF_SIGPENDING without really having a signal queued >> is not having easily visible ugly consequences. > >what happens if you get a signal around the time the timeout fires?
Depends of what around means.
+ result = down_interruptible(sem); + del_timer(&dit_timer); + if (result < 0 && data.result < 0) + result = data.result;
This piece of code will catch the 'timeout arrived right before a signal' case. 'data.result' is set by the timeout handler, so it doesn't interfere.
Now, if the timeout arrives right after a signal was delivered but before the thread returns from down_interruptible, then it will also look like a timeout (as that code in the if statement will kick in) -- to some extent, it is 'right' theoretically, as it didn't get the sem before the time expired. TIF_SIGPENDING is still set, so the signal is not lost (unless I miss something else about the signal delivery engine).
The last case, if the timeout arrives after the signal and after down_interruptible returns, nothing in theory. There is a window where the timer could still execute before it is deleted and it would look like a timeout [which theoretically could be right too]. Maybe the result < 0 && data.result < 0 check should be done before del_timer().
Suggestions?
-- Inaky - 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/
| |