Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!ncoast!allbery From: allbery@ncoast.UUCP (Brandon S. Allbery) Newsgroups: comp.unix.wizards Subject: Re: bug in pclose(3) Message-ID: <13290@ncoast.UUCP> Date: 26 Dec 88 21:29:40 GMT References: <261@ecijmm.UUCP> Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery) Followup-To: comp.unix.wizards Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 32 As quoted from <261@ecijmm.UUCP> by jmm@ecijmm.UUCP: +--------------- | I just tripped over a bug in the pclose library routine. If you do a | pclose on a file descriptor (that was opened with popen of course) in | some circumstances it will hang forever. For example: +--------------- From the manual page for popen(3) under System III: BUGS Only one stream opened by popen can be in use at once. This is less a bug than a misfeature; popen() is intended for casual use, not for complex tricks. If BSD Unix has a way to wait for a specific process ID, that could be used by pclose() (but I don't remember wait3() supporting that); the alternative is to have popen()/pclose() store the PID in a linked list, but then system() must also use that linked list -- and either new wrappers for exec?() must be made available or the use of system()/popen() and exec?() in the same program must be firmly discouraged. (And then someone will do it without reading the manual and complain about the "bug".) Moral: if you're going to play with multiple concurrent -- or even potentially concurrent -- subprocesses, do all the work manually. It takes more work to write the program, but the result is far more robust in a multi- process situation. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@.