Taking Control of stdin/stdout of a slave process

[Phong Vo[drew]]

In article <15500 at smoke.brl.mil>, gwyn at smoke.brl.mil (Doug Gwyn) writes:
: In article <1991Mar14.140749.24337 at cm.cf.ac.uk> bharat at cf-cm.computing-maths.cardiff.ac.uk (Bharat Mediratta) writes:
: -In article <1991Mar13.163756.26785 at evax.arl.utexas.edu> rduff at evax.arl.utexas.edu (Robert Duff) writes:
: ->I am interested in starting a UNIX process from a program and having the
: ->slave process' stdin and stdout piped through FILE*'s in the master process.
: ->I have worked with popen(), but that only allows one-way piping.
: ->How can I get both directions piped to my controller process?
...
: 
: The fellow said FILE*s, but in any case there is a fundamental problem
: with the request that has no simple solution.  Namely, deadlock can
: easily occur in such a scenario.  Only with a carefully-designed
: communication protocol can one have confidence that deadlock will not
: occur.  That requires support on the slave end as well as the master,
: so the slave cannot be an arbitrary process.
: 
Indeed there is no way to this with the current stdio. However,
a simple way to solve this problem is to introduce the notion of pool
auto-synchronization. A pool is a collection of streams (FILE*'s)
in which only one stream at a time can be done io on. All the other
ones are guaranteed to be synchronized. Now, to put this to work,
we need two things done automatically by the library:
1. popen() (or rather an appropriate extension of it) puts the two
   connecting streams into the same pool.
2. stdin and stdout if not seekable are put into the same pool.
Given these two features, deadlocks because of buffering and
simultaneous read requests can no longer arise. (2) also solves
the famous C-novice problem of what happens to the prompt:
	printf("Please type something: ");
	gets(buf);
I'll discuss the idea of stream pools and a few others this Summer
at Usenix in a joined paper with Dave Korn.