🚀 go-pugleaf

> Could you explain how interrupts are `passed on?'  Did the CTRL/Y
> interrupt handler get `passed on' to the (asynchronous) subprocess, and
> never `passed back?'  Why did my CTRL/Y interrupt the subprocess and not
> the parent process?  Why did the parent process lose CTRL/Y capability?

I don't know the exact mechanism by which access to interrupts is transferred
from one process to another, but I do know that the code for it appears
to be in the terminal driver (pretty much where you'd expect it), and that
it appears that there's a bug in TTDRIVER that causes this problem.  The
problem doesn't occur when the driver controlling the terminal is either
DZDRIVER or OPERATOR.  Thus, if you don't have virtual terminals enabled,
you don't see the problem.  My best guess (someday, if I don't hear from
some DEC person on the net that the problem's been fixed, I may get around
to reading the fiche to find the problem, assuming that it's not new to
VMS 4.5) is that when the asynchronous subprocess was spawned, it was handed
access to the interrupts.  Since the parent process wasn't watching for
the subprocess to die, it never realized that it was supposed to enable
interrupts for itself again.  Basically, the system seems to be trying to make
sure that only one process has access to the interrupts at any given time
(if you spawned a synchronous subprocess, if I recall correctly, both processes
have access to at least the control-t interrupt), but is doing this through
code related to termination mailboxes or something like that.  Again, I
have NOT read the fiche to figure out what the problem really is; the above
is pure guesswork and should not be taken seriously by anybody who wants
a reason for this behavior rather than a rationalization.