On 01/03/2014 09:45 AM, Alexey Perevalov wrote:As I understood alarm and deferrability it's type of repetition (timer trigger condition),On 01/03/2014 03:17 AM, John Stultz wrote:So while the alarm timers are a reasonable precedent, I think they wereOn 01/02/2014 10:30 AM, Alexey Perevalov wrote:I looked at alarm timers and found approach of making timer behaviorThis version introduces new clockid (CLOCK_DEFERRABLE) , forSo why did you make this change?
timerfd_create, instead of
new flag (TFD_TIMER_DEFERRABLE) for timerfd_settime introduced in
previous version.
thanks
-john
persistent per file descriptor is better than
changeable by timerfd_settime. I think "end user wake up from suspend"
and "don't wake up in idle" is the same thing on the same abstraction
level.
Yes Anton's previous patches worked with CLOCK_MONOTONIC only and I
didn't intend to use it with CLOCK_REALTIME, cause it's hard to me to
find such use case.
Another way - it's stay as was Anton's patch, I mean as flag for the
timerfd_settime, but in original patch set both hrtimer and deferrable
timers initialized in timerfd_create, I think it's not needed. Also
ability to change timer behavior looks not good if you couldn't change
alarm timer behavior, not unified API.
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).
Here I'm totally agree CLOCK_DEFERRABLE is not maintainable named constant.
Now that we have the timerfd interface, and if this functionality is
really limited to the timerfds, then we may want to consider what might
be, at least to me, the cleaner approach of using the flag.
Either way, I'd like to make sure we have a sound rational. My worry is
that deferrable timers would be desired on more then just
CLOCK_MONOTONIC, so we could quite likely end up with quite a few new
clockids (ie: CLOCK_BOOTTIME_DEFERRED, CLOCK_TAI_DEFERRED,
CLOCK_REALTIME_DEFERRED).
I meant, we couldn't use hrtimer for deferrability, right now.If I'm right, only high resolution timer could be REALTIME, and thereI'm not sure I understood this part. Could you explain further?
is no deferrable behavior for hrtimer only for timer_list.
thanks
-john