Messages in this thread | | | Date | Wed, 19 Jan 2005 15:51:32 -0800 | From | George Anzinger <> | Subject | Re: patch to fix set_itimer() behaviour in boundary cases |
| |
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.
For what its worth, you can tell it was truncated by reading back the remaining time. That could be done in the glibc wrapper and an error passed back, but actually doing the proper wait using this interface is rather hard.
The timer_settime(CLOCK... interface detects overflow and passes back an error...
Clock_nanosleep on the otherhand, will sleep for the whole time, provide the machine doesn't turn to dust :) -- George Anzinger george@mvista.com 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |