Re: Problems with timerfd()

["Ray Lee" <ray-lk@madrabbit.org>]

On 7/24/07, Michael Kerrisk <mtk-manpages@gmx.net> wrote:
> > On 7/22/07, Michael Kerrisk <mtk-manpages@gmx.net> wrote:
> > > 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?
>
> The value returned by read() is the number of overruns since
> the last read().

Okay, and this is an application local count, yes? (Not system-wide.)

> > That makes
> > it oblivious to rollovers, unless it can't manage to do a read once
> > every 11 hours.
>
> That's the point that the change is meant to address.

Once every 11 hours isn't a terrible price to pay. Once every 11
seconds would be another matter. It doesn't seem unreasonable to
expect an application that is already actively dealing with timers to
go and take a look at things every hour to see if there have been more
overruns.

> > (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.)
>
> But userspace can't deal with the condition accurately,

Okay, perhaps this is where I'm missing something? If userspace wakes
up once every hour, checks the overrun counter against the previous
(new-old), and goes back to sleep, that'd be good enough, right?

> so why
> require userspace to worry about this when we could just use
> a 64-bit value instead?

<shrug> I don't have strong feelings either way. It just seemed like
something that could already be taken care of with today's interface.
Given that the discussion was about an API change between 2.6.22 and
2.6.23, I was looking for options to avoid that.