a proposed callout API

[Robert Watson]

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