From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 27-JUL-1993 16:03:03.25 To: EVERHART CC: Subj: Re: Parent/Child problem - counseling needed! Message-Id: <9307270402.AA29853@uu3.psi.com> Date: Tue, 27 Jul 93 00:02:39 EDT From: Jerry Leichter To: INFO-VAX@sri.com Subject: Re: Parent/Child problem - counseling needed! X-Vms-Mail-To: UUCP%"houseman@hopper.ACS.Virginia.EDU" [Carl Houseman asked the original question, which is summarized in Carl Lydick's response:] >[SPAWN asynchronous subprocess, after subprocess terminates, control >C, Y, and T don't work properly with parent process; spawning a >synchronous subprocess and having it log out fixes the problem] > >It's an old bug. It's been around since version 4.something. For >the situation you describe, the easiest workaround is probably to >have the parent process call LIB$SPAWN with "LOGOUT" as the command >and the NOWAIT bit cleared after it deletes the first subprocess and >before it exits. [Mr. Houseman now writes:] Thanks, I'm glad to know it's not *my* code. Trouble is, I'm not into easy workarounds. :-) How can I avoid the extra LIB$SPAWN if it's not needed? Is there any way for my program to detect that the bug needs fixing? A bit more background as to the cause of the problem: All of CTRL/C, /Y, and /T cause AST's to be delivered to the process (an OOB (out-of-band) AST for CTRL/T, and usually the special CTRL/C and/or CTRL/Y AST's for the others). The terminal driver keeps a list of requested OOB and CTRL/C-CTRL/Y AST's, and walks the list, queing AST's, when the appropriate character arrives. Prior to some version of VMS (I think V4.0), the AST's were queued for all the request found. However, some of those corresponded to processes that were currently blocked in DCL because they had executed a SPAWN or an ATTACH to another process. The AST's would remain queued, only to be delivered much later, when the processes involved were again attached to the terminal. By then, they were irrelevent; but they could disrupt the code in those processes if it wasn't ready for this, In V4.0, the terminal driver got more clever. It keeps track of the process ID of a single "attached" process which it takes as the only one really talking to the terminal. When a CTRL/T or similar character arrives, only those AST requests that came from the "attached" process are queued; the others are ignored (the requests remain in the driver's queue for later use). How does the "attached" process get set? DCL issues a QIO to the control terminal, using an undocumented option (as I recall, it's an undocumented SETMODE). The bug comes up when you hop around processes in such a way that the "attached" process recorded by the terminal driver is not updated properly. What usually ends up happening is that the recorded value is the PID of a process that has exitted. As a result, no OOB or CTRL/C-Y AST's will be delivered at all. There is no simple way for you to detect this fact. (Kernel-mode code could find the UCB for the control terminal and check the appropriate longword, but is it really worth it?) Mr. Lydick's fix simply causes a situation in which DCL will declare some new process the "attached" process, thus clearing the logjam. You could do the same yourself if you looked up the undocumented QIO, but if I were you I'd stick to the SPAWN technique - the overhead should be quite small if you make sure not to pass DCL symbols, logicals, or key definitions to the created process. Yes, it's a hack ... but it does work. -- Jerry