Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...

Nicholas Miell
2007-03-10T21:06:18Z

On Sat, 2007-03-10 at 12:41 -0800, Davide Libenzi wrote:
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
>
> > Try reading the timer_create man page.
> >
> > In short, you're limited to a single clock, so you can't set timers
> > based on wall-clock time (subject to NTP correction), monotomic time
> > (not subject to NTP, will not ever go backwards or skip ticks), the
> > high-res versions of the previous two clocks, per-thread or per-process
> > CPU usage time, or any other clocks that may get introduced in the
> > future.
>
> One timer per fd yes. So?

I never complained about one timer per fd (although, now that you
mention it, that would get a bit excessive if you have thousands of
outstanding timers).

> The real-time and monotonic selection can be added.

IOW, the timerfd patch is not suitable for inclusion as-is. (While
you're at it, you should probably add a flags argument for future
expansion.)

> If you look at the posix timers code, that's a bunch of code over the real
> meat of it, that is hrtimer.c. The timerfd interface goes straight to
> that, without adding yet another meaning to the sigevent structure,

That's what the sigevent structure is for -- to describe how events
should be signaled to userspace, whether by signal delivery, thread
creation, or queuing to event completion ports. If if you think
extending it would be bad, I can show you the line in POSIX where it
encourages the contrary.

> and
> yet another case inside the posix timers trigger functions. That will be
> as unstandard as timerfd is, and even more, since you cannot use that
> interface and hope to be portable in any case.

If Linux were to do a wholesale theft of the Solaris interface (warts
and all), you'd be portable (and, now that I think of it, more
efficient).

Two major unixes using the same interface would probably make it a
shoe-in for the next POSIX, too. (c.f. openat(2) and friends)

> On top of that, handing over files to the posix timers will creates
> problems with references kept around.
> The timerfd code is just a *really* thin layer (if you exclude the
> includes, the structure definitions and the fd setup code, there's
> basically *nothing*) over hrtimer.c and does not mess up with other kernel
> code in any way, and offers the same functionalities. I'd like to keep it
> that way.

--
Nicholas Miell <nmiell@comcast.net>