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

From: John Stultz
Date: Thu Jan 09 2014 - 15:33:13 EST


On Sun, Jan 5, 2014 at 11:33 AM, Alexey Perevalov
<a.perevalov@xxxxxxxxxxx> 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?

thanks
-john
--
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/