Re: [PATCH 0/3] Deferrable timers support for timerfd API

[Alexey Perevalov <a.perevalov@samsung.com>]

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