[lkml]   [2007]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: RFC/patch: down_timeout_interruptible()
>From: Arjan van de Ven []
>> 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().


-- Inaky
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-02-26 07:41    [W:0.042 / U:6.852 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site