Unix Interrupts

[der Mouse]

> In article <3102 at cup.portal.com>, Chuck_SirVAX_Staatse at cup.portal.com writes:
>> Does anyone know if UNIX supports a "Connect to Interrupt" facillity
>> similar to VMS or RSX.

Not out-of-the-box.  A kernel hacker can build something of the sort.
Presumably you need low interrupt latency.  Good luck: UNIX has a
tendency to spend large amounts of time (hundreds of microseconds) with
interrupts blocked, because part of the design philosophy is that any
amount of time a human can't notice is irrelevant.  This is not the
case if you are doing "real-time" work.

>> has anyone cobbled something together?  Target system is a 68000 VME
>> based system.  Any takers?

At McGill here we built a fairly extensive system for robot control
that required "real-time" response.  We got it through the use of some
horrible kludges and by throwing security completely out the window.  I
can provide details if anyone is really interested; the system is a
MicroVAX-II running what started out as 4.3BSD.  (I say "started out
as" because we have had to do a good deal of hacking on it.)

In article <3617 at mtgzz.UUCP>, avr at mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) writes:
> UNIX provides a facility called "signals". Signals may be sent by
> processes, open device files, or by the kernel.  [suggests building a
> driver to send the process a signal on a device interrupt]

This will work fine, if you can tolerate the resulting latency.  A
signal can easily be delayed by twenty microseconds even if the process
is in-core, which is probably more latency than can be tolerated if
this application is such that it would use the connect-to-interrupt
driver on VMS.  And if the process happens to be swapped out to disk at
the moment, forget it.

					der Mouse

			uucp: mouse at mcgill-vision.uucp
			arpa: mouse at larry.mcrcim.mcgill.edu