Date: Mon, 10 Mar 2014 15:01:34 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Ryan Lortie <desrt@desrt.ca>, Baptiste Daroussin <bapt@freebsd.org>, hackers@freebsd.org Subject: Re: [CFR] Kevent timer improvements Message-ID: <201403101501.34306.jhb@freebsd.org> In-Reply-To: <1394461730.9823.92673865.45316D77@webmail.messagingengine.com> References: <20140310131632.GI6900@ithaqua.etoilebsd.net> <1394461730.9823.92673865.45316D77@webmail.messagingengine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, March 10, 2014 10:28:50 am Ryan Lortie wrote:
> hi Baptiste,
>
> Thanks for the patch! This helps us a lot and is already a very good
> fit for the way we manage event times in GLib.
>
> On Mon, Mar 10, 2014, at 9:16, Baptiste Daroussin wrote:
> > Note that NOTE_MONOTONIC is right only valid as EV_ONESHOT as the is the
> > behaviour that make sense to me concerning this kind of event, should it
> > be different? in that case what behaviour would be expected here?
>
> Speaking somewhat philosophically, it's my opinion that an absolute
> timer that is past its timeout is something like a pipe or socket that
> has polled as ready for input, but will never be read. In the case of a
> timer based on the real clock, the only way to reverse the condition
> would be to change the clock backwards. For monotonic time, there is no
> way to reverse the condition. This is distinctly different from
> periodic timers where the condition can become ready and then "more
> ready" just by the simple passage of more time.
>
> Ideally, I don't believe that we should implicitly add EV_ONESHOT or
> even EV_CLEAR to the event mask of absolute timer events. Although the
> user would typically want to do that for themselves, I don't believe
> that it makes sense to assume that for them -- they should have the
> choice, just as they do with pipes and sockets.
Absolute timeouts (whether CLOCK_MONOTONIC or CLOCK_REALTIME) don't make sense
as a repeating timer, so they are "oneshot" in that sense, but I do see what
you mean by wanting to have a timer that is level triggered and needs a manual
clear (so no EV_CLEAR).
At this point, it would be hard to make the EV_CLEAR optional for existing
timers without breaking lots of existing software. OTOH, we could allow
absolute timeouts (which are new) to require explicit EV_CLEAR. The absolute
timeout would just never rearm anything explicitly rather than requiring
EV_ONESHOT to get that as a side effect. There is actually a bug now (well,
dead code) in the current patch where it is trying to reschedule a timer in
filter_timerexpire() for an absolute timer. It should look like this instead:
filt_timerexpire()
{
...
KNOTE_ACTIVATE(kn, 0);
if (!(kn->kn_flags & EV_ONESHOT) && !(kn->kn_sfflags & NOTE_MONOTONIC)) {
// rearm the timer
}
}
Note that this removes all need for the 'flag' variable in filt_timerexpire().
You would also make the '|= EV_CLEAR' in filt_timerattach() conditional on
!(flags & NOTE_MONOTONIC).
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201403101501.34306.jhb>