🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: mod.computers.apollo
Article #275

Submission for mod-computers-apollo

#275
From: Robert Reed
Date: Mon, 17 Nov 1986 14:57
42 lines
2648 bytes
** 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 **
Technical Details
Message-ID: <862@zeus.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!rutgers!sri-unix!hplabs!ucbvax!zeus.tek.CSNET!bobr

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!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 <bobr%zeus.tek.csnet@RELAY.CS.NET>
Organization: The ARPA Internet
Lines: 42
Approved: apollo@yale-comix.arpa