[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <13c67e2c0809242105t77ca9a6k2faf1e85064967aa@mail.gmail.com>
Date: Wed, 24 Sep 2008 21:05:47 -0700
From: "Ani Sinha" <kernel@...rban.org>
To: linux-kernel@...r.kernel.org, kernel@...rban.org, mingo@...e.hu
Subject: wait_event_interruptible_timeout
I have noticed an issue with wait_event_interruptible_timeout() API
which I will try to explain below:
wait_event_interruptible_timeout() is supposed to wait until one of
the following happens:
(a) Timeout occurs (with no signals or the event of interest
happening), in which case it returns 0
(b) The process receives a signal and wakes up prematurely (i.e.,
before its timeout expired or the event of interest occurred). In this
case, it returns –ERESTARTSYS. I will come back to this later.
(c) Of course, the last obvious way to wake up is that the event of
interest occurs and it wakes up all (or one) process on the wait
queue. In that case, it returns the # of jiffies that is left before
the timeout would have occurred (unslept or balance jiffies).
What if I really wanted to sleep for timeout interval and no more?
That is to say, if I wake up on a signal and I wanted to know how many
jiffies I did used up while sleeping and how many I am left with (just
like poll or select does)? That way, when I retry the API, I can tell
it to sleep only by the amount of my balance sleeping time.
Unfortunately, the interface looses this information since it
overrides the return value with ERESTARTSYS. I feel there is a need to
modify the code in order to correct this behavior. I am more than
willing to propose a patch but before I do so, I wanted to know what
the community thinks about it.
Thanks,
Ani
P.S: Please CC me separately as I am not on the mailing list.
====
Anirban Sinha
GNU/Kernel Developer
Zeugma Systems, Canada.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists