Handle missed interrupts more gracefully #24
Description
Inside Macintosh warns strongly against doing synchronous IO at interrupt time, since this can cause interrupt-driven drivers (such as ours) to deadlock.
Unfortunately, some software does this anyway. Such a deadlock can easily be replicated by attempting to mount a large (>300MB) disk image in Disk Copy 6.3 over AppleShare on ethernet - after mounting the image, the system locks up inside a synchronous IO call which never completes because interrupts are masked. I'm not filing it as a bug, as the exact same lockup occurs using an Asante MacCon NuBus card on a Mac IIfx with Apple's own drivers.
However, it should be possible to handle this in a more graceful fashion and recover from it - in the Disk Copy case, manually failing the IO call in MacsBug (by setting the parameter block's return code to -1) unblocks the system and everything proceeds as normal (presumably the IO operation gets retried or something).
A possible solution could be to establish a timeout for interrupt handling, after which all pending IO would be failed. This in turn would require that the interrupt handler to run as a Deferred Task, so that it could be interrupted by a Time Manager task handling the timeout. Care would need to be taken to keep the driver and hardware in a sane state through this, but it should be at least somewhat more robust than having the system hang - notably the ae driver in A/UX does something similar, using a timeout to guard against missed interrupts or a 'stuck' transmitter.