Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!sgi!calcite!vjs
From: vjs@calcite.UUCP (Vernon Schryver)
Newsgroups: comp.unix.sysv386
Subject: Re: 8254 timer usage under Sys V/386 R3.2?
Summary: You know better that, Dick!
Message-ID: <107@calcite.UUCP>
Date: 2 Feb 91 21:29:57 GMT
References: <16808@ogicse.ogi.edu> <1991Feb1.202411.9033@ico.isc.com>
Organization: Rhyolite Software, Mountain View, CA
Lines: 34

In article <1991Feb1.202411.9033@ico.isc.com>, rcd@ico.isc.com (Dick Dunn) writes:
>  ...
> It's unfortunate that there isn't a free timer for other uses.  It would be
> very useful for both system and application tasks.  It would be nice if
> there were a simple I/O card with a programmable timer or two...couldn't
> take more than a few chips. ...

It would be far better to build something like the 4.*BSD itimers, or just
use select(2), even if you had to get to them thru a library that diddled a
cdev[] driver.  (Think of the old Excelan TCP code).  It's often said that
the only purpose of the kernel is to mediate among requests for resources.
A mechanism to allow an varying number of processes to use varying numbers
of what each process thinks are private, accurate, low overhead timers is
not trivial.  It's easy to blow several percent of a CPU on watching
timers, even when they are not in use.  Timers might be slightly easier to
implement well given a hardware clock independent of any of the 3 clocks in
the SV (lbolt, timeout(), and time), but I doubt it.  Consider that those 3
kernel clocks are often based on a single hardware interrupt at HZ/sec.

Imagine a trivial cdev[] driver that did little more than call timeout() in
response to an IOCTL.  It could have a hash table keyed on PID or file
table pointer, containing the ID obtained from timeout() to allow
cancelling timers in response to another IOCTL.  It would send the
requesting process a specified signal when the timeout expired, or simple
wakeup and return from an IOCTL.  Such a driver would take someone like
D.Dunn at most a day to implement, debug, and document.

A quick grep thru a copy of the SVR4 os/*.c showed me no signs of itimers.
I don't see how you could have decent BSD compatibility without them, but
they didn't call it SV without reason.  (Yes, the original article was
about SVR3.2.)


Vernon Schryver,   vjs@calcite.uucp