Path: utzoo!utgpu!watmath!iuvax!mailrus!cornell!rochester!dibble
From: dibble@cs.rochester.edu (Peter C. Dibble)
Newsgroups: comp.os.os9
Subject: Re: Interrupt handling error in most OSK drivers ???
Message-ID: <1989Aug18.030630.1686@cs.rochester.edu>
Date: 18 Aug 89 03:06:30 GMT
References: <1772@ethz.UUCP>
Reply-To: dibble@cs.rochester.edu.UUCP (Peter C. Dibble)
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 26

This is in reply to a question about device drivers, in particular the
gap between the time interrupts are unmasked and the F$Sleep to wait
for an interrupt.

The question was, roughly, if an interrupt arives and is serviced
before the driver sleeps and after it commits to sleep, isn't that
interrupt (actually the signal from the interrupt service routine) lost?

===

It turns out that the wakeup signal has a special property that makes it
queue... sort of.  A wakeup signal will either 
activate the target process or set the signal-pending flag for that
process.    It activates the process (basically) if the process is sleeping 
or waiting (either process wait or event wait).
The signal pending flag causes the next sleep (or wait) to
return immediately.  Signal pending is only cleared by sleep or wait.

Wakeup has had this property since OS-9/6809.  I haven't seen it documented.
This is something I should add if I do another edition of Insights.

Keeping interrupts masked right into the F$Sleep will work, but it leaves
interrupts masked for a _long_ time.  It'll cause serious performance
problems on systems that rely on fast interrupt response.

Peter