Date: Wed, 29 Nov 2006 13:46:00 -0500 From: John Baldwin <jhb@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-arch@freebsd.org Subject: Re: a proposed callout API Message-ID: <200611291346.01246.jhb@freebsd.org> In-Reply-To: <20061129104205.C95096@fledge.watson.org> References: <7105.1163451221@critter.freebsd.dk> <200611281631.19224.jhb@freebsd.org> <20061129104205.C95096@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 29 November 2006 05:45, Robert Watson wrote: > On Tue, 28 Nov 2006, John Baldwin wrote: > > > One note and one question. First, the note. I was planning on rototilling > > our sleep() APIs to 1) handle multiple locking primitives, and 2) use > > explicit timescales rather than hz. I had intended on using microseconds > > with a negative value indicating a relative timeout (so an 'uptime' timeout, > > i.e. trigger X us from now) and a positive value indicating an absolute > > timeout (time_t-ish, and subject to ntp changes). Partly because (IIRC) > > Windows does something similar (negative: relative, positive: absolute, and > > in microseconds too IIRC) and Darwin as well. Part of the idea was to fix > > places that abused tsleep(..., 1), etc. to figure out a "real" sleep > > interval. With your proposal, I would probably change the various sleep > > routines to take a tick_t instead. That leads me to my question if if you > > would want to support the notion of absolute vs relative timeouts? > > I realize that Windows has established something of a convention here, but I > would prefer it if we had different APIs for absolute and relative timescales, > rather than overloading the signed value. I would instead like to either pass > in an unsigned value (giving compile-time checking, especially with gcc4), or > pass signed and assert it's > 0 in the relative case (to give runtime > checking). We could also generate run-time warnings for absolute times in the > past, and so on. Especially if we start to move towards rescheduling callouts > in order to reduce the size of the outstanding callout queues (TCP uses 4+ per > connection now, and 1 would be a better number), time offset arithmetic is > likely to be error prone, and catching these problems sooner rather than later > would be good. Different APIs would be fine. IIRC, that's how Darwin does it. With the tick_t idea, you could easily have: tick_t relative_wakeup(ulong nsec) tick_t absolute_wakeup(struct timeval *tv) (or something else, etc.) Doing it that way would let us stay as we are for now (just supporting the relative "uptime" timeouts) and investigate whether or not we want walltime timeouts (such as for TCP as Poul-Henning mentioned). I like tick_t, I just want to make sure we change foosleep() to use it as well, and wanted to raise the idea of relative vs absolute deadlines. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611291346.01246.jhb>