Messages in this thread | | | Date | Mon, 9 Feb 2009 12:10:23 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [patch 2/2] timerfd extend clockid support |
| |
On Tue, 10 Feb 2009, Michael Kerrisk wrote:
> > and I did not have even the time to peek > > into the core timer code to see if the usage of other timer types in > > eventfd would create problems. That's why I asked Thomas if they'd behave > > differently from an hrtimer caller POV. > > I'll try to take a look by myself today or tomorrow. > > Okay -- hopefully my test program may be useful (even if it is not > itself fully tested yet, it's patterned after a similar test program I > wrote fot the POSIX timers API, so it should mostly work).
Answer was pretty easy once you look at the code :) Timerfd uses core hrtimer functions, and clockids different from the ones timerfd already handles, fall into the CPU-timers domain. Domain that is not handled by hrtimer. Changes to timerfd to support CPU-based timers are really deep (more than changes, is a total rewrite). not only to timerfd, but also to CPU-based timers to deliver notification by means different than signals. Given the amount of code change, and given that a posix-timers->signalfd bridge could solve the problem, I'm not going even close to suggest such a change.
- Davide
| |