Date: Mon, 22 Dec 1997 00:08:48 -0800 (PST) From: "J. Weatherbee - Senior Systems Architect" <jamil@acroal.com> To: hackers@freebsd.org Subject: Am I off my rocker? (/dev/tick device) Message-ID: <Pine.BSF.3.96.971221234402.2497A-100000@acroal.com>
next in thread | raw e-mail | index | archive | help
I certainly hope this does not already exist . . . I was thinking about a certain application I've been working on the makes extensive use of synchronous I/O multiplexing (e.g. select(2) or poll(2)). The environment is such that for the most part using a timeout in these calls are unnecessary, since for any reasonable timeout select() will return first with descriptors ready for I/O. Also, these devices for the most part (serial & analog ports) predictably periodically become ready for read. I may be dealing with 64 or so descriptors, but I thought it might be useful to have a /dev/tick pseudo device that would come ready for i/o say 10-100 times a second (depending on an ioctl). So suppose you open this device, and ioctl() it to 10 hertz, if you went into select() it would return ~100ms after opening the read ready on the /dev/tick fd. When you call read on /dev/tick, you get a unsigned int representing the number of microseconds (or alternately milliseconds) elapsed since the descriptor was opened. Milliseconds would be better, since that is at the limit of it usefulness and the descriptor would only turn over once every 49 days. Or better yet, let the frequency be user ioctl() controllable. I prefer to think of the I/O multiplexed method of writing multiuser daemons, as kind of processing one big aggregrate stream of data. With a /dev/tick fd in there the stream would have some predictable processing rate. In this case, very useful for real-time priority processes. I am confident I could author this pseudo-device (but that doesn't mean it is a good idea), so I want some feedback.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971221234402.2497A-100000>