Messages in this thread | | | Date | Sun, 12 Jan 2014 21:16:42 +0400 | From | Alexey Perevalov <> | Subject | Re: [PATCH 0/3] Deferrable timers support for timerfd API |
| |
On 01/10/2014 12:32 AM, John Stultz wrote: > On Sun, Jan 5, 2014 at 11:33 AM, Alexey Perevalov > <a.perevalov@samsung.com> wrote: >> On 01/04/2014 04:18 AM, John Stultz wrote: >>> So while the alarm timers are a reasonable precedent, I think they were >>> introduced prior to the timerfd interface, so it seemed at the time >>> having new clockids for the functionality was required to work with the >>> existing syscalls that use the clockid (Though in retrospect, I question >>> if it would have been better to use timer flags to introduce the alarm >>> functionality rather then introducing it via a clockid, as it would >>> simplify the clockid definitions). >> As I understood alarm and deferrability it's type of repetition (timer >> trigger condition), >> but REALTIME, BOOTTIME, MONOTONIC it's a type of time representation. >> Mixed it in one clockid, maybe it's a controversially. Which flags do you >> want to use, flags of timerfd_settime? > Well, my first reaction was just to suggest you create a new timer > flag (like TIMER_ABSTIME) TIMER_DEFER, which we could then consider > adapting as a new flag value for all the timer related code > (posix-timers, nanosleep, etc). > > Then looking closer at the timerfd code, I see I wasn't aware there's > some additional constraints as the timerfd flags overlap with many of > the file O_ flags, and that the timerfd has its own TFD_TIMER_ABSTIME. > I'm not quite sure I recall the context of that decision, so it might > be good to involve those who recall more of that history. So I'm not > sure which particular bit flag would be best to take there. Anton's > patch took (1<<2), so I'm guessing that's still ok. > > Anyway, adding something like a TFD_TIMER_DEFER along with TIMER_DEFER > would seem to me like a reasonable approach. > > Addtionally the TFD_CANCEL_ON_SET is interesting in that we don't have > a similar flag for the posix timers interfaces. Do you think there's > any value in looking into unifying that as well? Posix timer doens't have cancel_list ability right now. Do you want to add such ability? With posix timer there is no problem of interference O_ flags, and flag for posix timer might have the same value as TFD_TIMER_CANCEL_ON_SET, and appropriate name.
Version of Anton's patches with flag based interface I'll send tomorrow. But with little modification in overruns, I think evaluation based on hrtimer for overrun is not proper way for deferrable timer, because in most cases number of deferrable ticks is lesser.
> thanks > -john >
-- Best regards, Alexey Perevalov
| |