Messages in this thread | | | Date | Mon, 23 Jul 2007 09:55:16 -0700 | From | "Ray Lee" <> | Subject | Re: Problems with timerfd() |
| |
Hey there Michael, all,
On 7/22/07, Michael Kerrisk <mtk-manpages@gmx.net> wrote: > Problem 1 > --------- > > The value returned by read(2)ing from a timerfd file descriptor is the > number of timer overruns. In 2.6.22, this value is 4 bytes, limiting the > overrun count to 2^32. Consider an application where the timer frequency > was 100 kHz (feasible in the not-too-distant future, I would guess), then > the overrun counter would cycle after ~40000 seconds (~11 hours). > Furthermore returning 4 bytes from the read() is inconsistent with eventfd > file descriptors, which return 8 byte integers from a read().
I'm feeling slow, and think I'm missing something. Why is this an issue? Wouldn't userspace just keep track of the last overrun count, and subtract the two to get the overruns-since-last-read? That makes it oblivious to rollovers, unless it can't manage to do a read once every 11 hours.
(This is the same sort of thing we already have to deal with in certain situations, such as network stat counters on 32 bit platforms.)
Ray - 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/
| |