From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 10 19:02:06 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91FFCE7F; Mon, 10 Mar 2014 19:02:06 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 54F2AA3; Mon, 10 Mar 2014 19:02:06 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3B065B9B9; Mon, 10 Mar 2014 15:02:05 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: [CFR] Kevent timer improvements Date: Mon, 10 Mar 2014 15:01:34 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140310131632.GI6900@ithaqua.etoilebsd.net> <1394461730.9823.92673865.45316D77@webmail.messagingengine.com> In-Reply-To: <1394461730.9823.92673865.45316D77@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201403101501.34306.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 10 Mar 2014 15:02:05 -0400 (EDT) Cc: Ryan Lortie , Baptiste Daroussin , hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 19:02:06 -0000 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