[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.021 / U:12.696 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site