| fjblurt@yahoo.com 2007-12-14, 7:23 pm |
| On Dec 14, 4:35 pm, David Mathog <mat...@caltech.edu> wrote:
> In a previous thread I asked if it was possible to pass a working fd
> (other than stdin, stdout, stderr) to a child process created with
> execlp(), and the consensus was that it was not.
It *is* possible, via Unix domain sockets. Paul Pluzhnikov said "Not
portably" but gave a reference to section 15.3 of Stevens' APUE, and
if you read it you'll see that the fact is that it can be done on many
systems, and details on how to do it. What system do you have in
mind?
> (
> Thread title: access to fd created AFTER a child splits off with execlp
> The URL, which will probably wrap, is:
>
> http://groups.google.com/group/comp...e_thread/thr...
>
> }
>
> I then asked if it was possible to break a socket pair and reattach one
> end in the execlp() child, and the one reply to that was that also was
> not possible.
>
> Just for completeness, presumably this also means that a network socket
> cannot be reconnected to a (sub)process started with execlp()?
>
> 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".)
"Filter" might be a more common term.
> 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.
> The first being slow and the second complicated.
>
> The only other method I have thought of so far to "cut into the data
> stream" is to expose the data stream to a function with a fixed
> name which is loaded through an explicit dlopen(), targeted to the
> location of the specified modules. So in the code:
>
> while(ok){
> get_data(pointer_to_data_structure);
> process_data(pointer_to_data_structure);
> write_data(pointer_to_data_structure)
>
> }
>
> process_data() would come in through an explicit dlopen(). That side
> steps all the data stream issues, but makes passing the parameters for
> each variant of process_data() a little tricky. (For instance, one
> cassette might have a parameter "-dog=beagle" and another cassette a
> parameter "-cat=siamese", but neither cassette has the other's
> parameter.) Also each such plugin would have to be built as a shared
> library, and I can imagine all sorts of portability issues with that.
There are lots of programs that do something like this. As an example
which I have open right now, the XMMS music player has "plugins" which
are dynamically loaded objects which do exactly that. Media players
often handle many different encoding schemes via dynamically loaded
"codecs", which is much the same thing.
You design some sort of common interface for your plugins; perhaps
they have functions called initialize(), set_parameters(),
filter_data(), etc. With dlopen and dlsym you can easily load lots of
plugins and get pointers to their functions, and call them as
appropriate. The usual way to handle parameters is to have a syntax
which identifies which options go to which plugin, e.g.
main_program -dog-plugin-opts=beagle -cat-plugin-opts=siamese
and then you pass the string "beagle" to the "dog" plugin, which is
responsible for parsing it further if necessary.
Doing shared objects portably is not so bad as it used to be.
Something like GNU libtool might help you.
IMHO this sort of design will be more familiar to people than having
your filters in separate programs, so I'd be inclined to investigate
further to see if it will work for you.
|