Date: Mon, 10 Mar 2014 14:49:30 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: desrt@desrt.ca, John-Mark Gurney <jmg@funkthat.com>, hackers@freebsd.org, Baptiste Daroussin <bapt@freebsd.org> Subject: Re: [CFR] Kevent timer improvements Message-ID: <201403101449.30958.jhb@freebsd.org> In-Reply-To: <20140310182333.GJ32089@funkthat.com> References: <20140310131632.GI6900@ithaqua.etoilebsd.net> <20140310182333.GJ32089@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, March 10, 2014 2:23:33 pm John-Mark Gurney wrote: > Baptiste Daroussin wrote this message on Mon, Mar 10, 2014 at 14:16 +0100: > > A glib developer pointed me to some of the improvements Apple has done on > > kqueue(2), some of those improvements are used or will be used by glib in the > > near futur, plus add new one. > > > > I decided to implement part of it and here is the first patch about it: > > http://people.freebsd.org/~bapt/kevent.diff > > > > I will update the manpages accordingly as well: > > > > Basically this patch added the following to the EVFILT_TIMER: > > NOTE_SECONDS data is in seconds > > NOTE_USECONDS data is in microseconds > > NOTE_NSECONDS data is in nanoseconds > > Could you contact the maintainer of sbintime and look at adding an > SBINTIME_MAX/_MIN define macros and use those instead of INT64_MAX? We > shouldn't know the internal implementation type of sbintime_t in the > code in case the type changes... > > > I do plan to add kevent64 support compatible with apple implementation later, as > > using NOTE_MONOTONIC without 64bit support is not useful very long :) > > Is this just to support 64bit data on a 32bit system? Also, why is > ident grown to 64bits? I don't see any filters that could possibly > need the additional range... I can understand data be expanded to > 64bits... > > Also, what exactly is ext used for? I'm looking at MacOSX's description > of ext, and it isn't clear.. it basicly says "ext[0] is passed through > much like udata" (only much? not exactly like?), and "ext[1] can always > be used like udata"... It isn't clear how/what these are used for, etc.. > > It looks like the "much like udata" part is because using the > EVFILT_MACHPORT will overwrite it. If we do import this, I'd like to > be clear on how they are used, i.e. their use is specified by the > filter, and if the filter does not use them, they are exactly like > additional udata fields.. Yes, my reading is that that is what they are in practice on OS X, but the manpage has rotted. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201403101449.30958.jhb>