wait_event_interruptible_timeout

wait_event_interruptible_timeout

[Ani Sinha]

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.

Re: wait_event_interruptible_timeout

[Oleg Nesterov]

On 09/24, Ani Sinha wrote:
>
> 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)?

You can read jiffies before and after wait_event_interruptible_timeout().

> That way,  when I retry the API, I can tell
> it to sleep only by the amount of my balance sleeping time.

Something like

	unsigned long now = jiffies;
	ret = wait_event_interruptible_timeout(..., timeout);
	if (ret < 0) {
		next_timeout = now + timeout - jiffies;
		if (next_timeout < 0)
			next_timeout = 0;
	}

We can even add another wait_ helper which treats "timeout" as lvalue
and updates it before return. I dunno.

> Unfortunately, the interface looses this information since it
> overrides the return value with ERESTARTSYS.

Yes you are right, but

> I feel there is a need to
> modify the code in order to correct this behavior.

I'm afraid it would be a pain to modify this API. But please
do not hesitate to make the patch if you think the current API
can be improved. At worst, the patch will be nacked ;)

Oleg.

Re: wait_event_interruptible_timeout

[Anirban Sinha]

On 25-Sep-08, at 9:45 AM, Oleg Nesterov wrote:
>
>
> We can even add another wait_ helper which treats "timeout" as lvalue
> and updates it before return. I dunno.


I agree. I think adding a new wait_ helper is probably the cleanest  
way to go since any updates to the old helper might break the kernel  
at numerous other places. I am sending the patch in my next email.

Thanks for responding,

Ani