In article <fjv7gf$heb$1@naig.caltech.edu>,
David Mathog <mathog@caltech.edu> wrote:

> The reason all of this comes up is, an existing program currently just
> copies information in from one (or more) node(s) and then out to
> one (or more) node(s) over the network.  That works fine.  What I'm
> trying to add now is the the ability to call up another program to cut
> into that data stream and do something more complicated with it.  There
> could conceivably be many such functions, so I wanted them to live in
> separate programs and be specified by a command line parameter on the
> main program.  (For lack of a better word, call them  "cassettes".)
> Moreover, these cassette programs have their own command line parameters
> which the master would pass into them via the execlp() call.  If the
> data stream cannot be reconnected from the master to the slave (the
> cassette program), getting the data stream into and out of the slave
> process becomes complicated: it either requires copying through named
> pipes or setting up a shared memory interface between the two programs.

Can you specify a common command-line parameter scheme for your
cassettes?

If so, what you can do is specify that cassettes always take a parameter
that specifies the descriptor of the network connection, e.g.

cassettename --fd=123

Since processes run via exec inherit the parent's open streams (except
those that have had the close-on-exec flag set, of course), the cassette
can retrieve this parameter and then start using the data stream in that
FD.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

[ Post a follow-up to this message ]