Re: patch to fix set_itimer() behaviour in boundary cases

[George Anzinger <george@mvista.com>]

Arjan van de Ven wrote:
> On Wed, 2005-01-19 at 15:51 -0800, George Anzinger wrote:
> 
>>Arjan van de Ven wrote:
>>
>>>On Sun, 2005-01-16 at 00:58 +0000, Alan Cox wrote:
>>>
>>>
>>>>On Sad, 2005-01-15 at 09:30, Andrew Morton wrote:
>>>>
>>>>
>>>>>Matthias Lang <matthias@corelatus.se> wrote:
>>>>>These are things we probably cannot change now.  All three are arguably
>>>>>sensible behaviour and do satisfy the principle of least surprise.  So
>>>>>there may be apps out there which will break if we "fix" these things.
>>>>>
>>>>>If the kernel version was 2.7.0 then well maybe...
>>>>
>>>>These are things we should fix. They are bugs. Since there is no 2.7
>>>>plan pick a date to fix it. We should certainly error the overflow case
>>>>*now* because the behaviour is undefined/broken. The other cases I'm not
>>>>clear about. setitimer() is a library interface and it can do the basic
>>>>checking and error if it wants to be strictly posixly compliant.
>>>
>>>
>>>why error?
>>>I'm pretty sure we can make a loop in the setitimer code that detects
>>>we're at the end of jiffies but haven't upsurped the entire interval the
>>>user requested yet, so that the code should just do another round of
>>>sleeping...
>>>
>>
>>That would work for sleep (but glibc uses nanosleep for that) but an itimer 
>>delivers a signal.  Rather hard to trap that in glibc.
>>
> 
> This one I meant to fix in the kernel fwiw; we can put that loop inside
> the kernel easily I'm sure

Yes, but it will increase the data size of the timer...


-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/