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

[Davide Libenzi]

On Sat, 10 Mar 2007, Nicholas Miell wrote:

> 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).

Right, of course.



> > 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.)

That's already in.



> > 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.

I'm sorry, I already explained you that linking the two (files and posix 
timers) is going to create more troubles than it actually solves.
The timerfd code provides the same functionality, with zero intrusion in 
existing code, and basically zero code (once if you remove the usual fd 
creation/cleanup).
The code of adding posix timers support would be *all* the existing one
(that is already a thin wrapper that calls hrtimer.c support - like 
posix timers do), plus adding more crud into the posix timers code, plus 
adding file references handling. If *you* want to do that, I can open you 
a door into the timerfd.




- Davide


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/