Date: Wed, 29 Nov 2006 10:45:30 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-arch@freebsd.org Subject: Re: a proposed callout API Message-ID: <20061129104205.C95096@fledge.watson.org> In-Reply-To: <200611281631.19224.jhb@freebsd.org> References: <7105.1163451221@critter.freebsd.dk> <200611281631.19224.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061129104205.C95096>