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

[George Anzinger]

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@xxxxxxxxxxxx> 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@xxxxxxxxxx
High-res-timers:  http://sourceforge.net/projects/high-res-timers/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/