[CFR] Kevent timer improvements

[John Baldwin]

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