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