popen and deadlock (was Re: UNIX commands in C)
Jonathan I. Kamens
jik at athena.mit.edu
Tue Apr 30 06:44:17 AEST 1991
(Note: comp.lang.c is not relevant to this discussion. Popen() is not in
the ANSI C spec, and is not a C thing, it's an OS-dependent thing. The people
in comp.lang.c get a little upset when people start talking about OS-dependent
functions in that newsgroup.)
In article <174 at shasta.Stanford.EDU>, shap at shasta.Stanford.EDU (shap) writes:
|> popen(3) also has an interesting "feature." It is essentially useless
|> unless the program you run from it doesn't read from stdin. Here's
|> why.
|>
|> ...
|>
|> 2. Child program (the filter) processes some input and writes
|> results to it's output (which the parent will eventually
|> read).
Um, because of the deadlock problems you describe, peopen was specifically
designed to allow only one channel through which the parent can talk to the
child -- either the parent writes to the child and the child sends its output
to stdout, or the parent reads from the child and the chid gets its input from
stdin.
Yes, you can circumvent this, by playing games with stdout and stdin, but if
you do that, then you deserve to lose, and it is *you* who are introducing the
problem, not popen.
So it is completely inaccurate to say that, when using popen, the parent can
send output to the child and the parent will eventually read the child's
output in response. That's not popen.
This is all addressed in question number 26 in the comp.unix.questions
Frequently Asked Questions posting, which even says where to get source code
for a set of routines that allows you to do two-way communication with a child
process without deadlock problems.
--
Jonathan Kamens USnail:
MIT Project Athena 11 Ashford Terrace
jik at Athena.MIT.EDU Allston, MA 02134
Office: 617-253-8085 Home: 617-782-0710
More information about the Comp.unix.questions
mailing list