Re: Portable IPC

[Brian Dessent]

Bill Moseley wrote:

> I suspect this is beyond the scope of the autoconf list.
> 
> Our application, Swish-e, can use "filters" -- which are external
> programs that filter input and the application reads the output from
> the filter program.
> 
> Besides the fact that my unix IPC skills are not that great, I'm
> wondering if there's any examples someone can point me to that use
> autoconf tests for fork/exec/wait written in a reasonably portable
> way (whatever that means).
> 
> Currently, I assume if HAVE_WORKING_FORK is defined that I can also
> have pipe(), dup2(), and fdopen().
> 
> Another example, here's a first pass at the function to close the filter
> program -- which might happen before the filter has finished
> generating all its output.
> 
> What I'm concerned with is knowing what features need to be tested for
> in configure.

OT - I wouldn't consider that IPC.  When you say IPC, I think
semaphores, shared memory, unix-domain sockets, that kind of thing, but
not just simply spawning a subprocess and reading/writing to a pipe. 
But maybe I have a strange definition of IPC.

You might want to look into gnulib, specificially the modules
"wait-process", "execute", and "pipe".  If you do it that way, you don't
have to worry about how the underlying system handles process creation
and pipes, so your code will also work on systems like mingw where the
means to accomplish your task exist but not through the traditional
posix APIs of fork/exec/pipe/whatever.

Brian