Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-unix!hplabs!ucbvax!zeus.tek.CSNET!bobr From: bobr@zeus.tek.CSNET (Robert Reed) Newsgroups: mod.computers.apollo Subject: Submission for mod-computers-apollo Message-ID: <862@zeus.UUCP> Date: Mon, 17-Nov-86 09:57:26 EST Article-I.D.: zeus.862 Posted: Mon Nov 17 09:57:26 1986 Date-Received: Mon, 17-Nov-86 21:48:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Robert Reed Organization: The ARPA Internet Lines: 42 Approved: apollo@yale-comix.arpa ** Forwarded Message Follows ** Path: zeus!bobr From: bobr@zeus.UUCP (Robert Reed) Newsgroups: mod.computers.apollo Subject: Domain/IX signals, subprocesses and psuedottys question Date: 13 Nov 86 22:24:32 GMT Reply-To: bobr@zeus.UUCP (Robert Reed) Organization: CAE Systems Division, Tektronix, Inc., Beaverton, OR. Lines: 30 In trying to port a program currently running under UNIX[TM of AT&T] 4.3BSD to Apollo Domain/IX, I've run into a series of hitches. The program forks a shell which execs a program after setting up a pty/tty pair to receive the data. The data is received in the parent process by issuing a select call and then reading from the file descriptors which respond. The parent program has defined a signal handler to catch the death of the child process and initial processing will clean up the select mask. The problem is that the signalling mechanism apparently fails somewhere along the way. The parent program gets caught in a loop where the select fails due to an improper mask (the pty/tty having apparently been closed), and although there are indications that the signal handler has been called, nothing seems to come of its action. Has anyone had any similar experiences? Am I dealing with some sore of Apollo bug? Are there known differences in dealing with Domain/IX processes rather than 4.3BSD processes? Here are some particulars: There is a signal handler instantiated to respond to SIGCLD (the Apollo Child Died signal). Using debug, a breakpoint at the head of this routine is reached if it is the only breakpoint. But if breakpoints are set both here and at the head of the select loop, the signal handler breakpoint is apparently never reached. This particular circumstance sounds almost like a race condition, where interrupts caused by the debugger are sufficient to cause the loss of the signal. I have a call into Apollo central, but so far they've been no help. -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK ** End Forwarded Message **