Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site istbt.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxj!mhuxr!ulysses!allegra!mit-eddie!godot!harvard!seismo!mcvax!ukc!qtlon!istbt!andy From: andy@istbt.UUCP (Andy Greener) Newsgroups: net.unix-wizards,net.bugs.usg Subject: Shell out bug in pg (but a more general problem) Message-ID: <12@istbt.UUCP> Date: Thu, 28-Feb-85 07:33:26 EST Article-I.D.: istbt.12 Posted: Thu Feb 28 07:33:26 1985 Date-Received: Sat, 9-Mar-85 08:33:31 EST Organization: Imperial Software Technology, London, England Lines: 37 Xref: watmath net.unix-wizards:12339 net.bugs.usg:189 We recently had an intermittent problem when using the "shell out" in pg (Sys V.2 on Vax 750). Depending on the length of the preceding pipeline (the problem only occurs when pg is the tail of a pipeline) pg would resume without waiting for the child shell to complete - result: two processes trying to read from the terminal. On investigating in the pg source I found that it does a "wait(0)" without testing the return pid (this "mechanism" is common in Sys V code as far as I can tell). It is relying on the wait being interrupted by the death-of-a-child signal when the sub-process terminates. However, the Sys V shell makes the last process in a pipeline the parent of all the others, so if the pipeline contains a few processes the first may already have died, resulting in the wait(0) returning immediately and pg carrying on its merry way. It seems that this practice of relying on a signal to terminate the wait is inherently dangerous, especially as the signal(2) man section states in reference to SIGCLD and SIGPWR: "Their use in new programs is strongly discouraged" Does one hand at AT&T know what the other is doing? It is almost beyond comprehension that such a major screw up has seen the light of day. It undoubtedly will produce unforseen effects elsewhere (eg Sys V tar forks mkdir, and uses the same wait mechanism - we had problems here too). Do they do any testing of their "products"? My impression of Sys V.2 is that it was rushed out the door; there are other problems which we have come across that are really only of interest to other Sys V sites. I won't bore you with the details here, but I will respond to mailed requests and if there's lots of interest I'll post to the net. Andy Greener Imperial Software Technology London, ENGLAND. {mcvax, qtlon, inset, root44}!ist!andy "UNIX System V: from now on consider it sub-standard"