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 <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
