tags:

views:

604

answers:

3

I would like to do the following inside a C program on a Linux os:

  • Create a PIPE using a syscall (or 2)
  • Execute a new process using exec()
  • Connect the process's STDIN to to the previously created pipe.
  • Connect the process's output to another PIPE.

The idea is to circumvent any drive access for performance purposes.

I know that the creation of pipes is quite simple using the PIPE system call and that I could just use popen for creating a pipe for input OR output purposes.

But how would you go about doing this for both input and output?

A: 

The easiest way is probably executing /bin/sh, this way you can use familiar shell syntax for specifying pipes and offload all complexities.

Something like:

execlp("sh", "-c", "cat /dev/zero | cat > /dev/null", NULL);
intgr
In some circumstances, this might work - with a different pipeline than the one above which just chews up the CPU. However, the question describes a process writing to the child and getting responses back from the child; in your example, the second cat would have to be feeding its output back to the first cat.
Jonathan Leffler
+4  A: 

You need to be quite careful with the plumbing:

  1. Call pipe() twice, one for pipe-to-child, one for pipe-from-child, yielding 4 file descriptors.
  2. Call fork().
  3. In child:
    • Call close() on standard input (file descriptor 0).
    • Call dup() - or dup2() - to make read end of pipe-to-child into standard input.
    • Call close() on read end of pipe-to-child.
    • Call close() on write end of pipe-to-child.
    • Call close() on standard output (file descriptor 1).
    • Call dup() - or dup2() - to make write end of pipe-from-child into standard output
    • Call close() on write end of pipe-from-child.
    • Call close() on read end of pipe-from-child.
    • Execute the required program.
  4. In parent:
    • Call close on read end of pipe-to-child.
    • Call close on write end of pipe-from-child.
    • Loop sending data to child on write end of pipe-to child and reading data from child on read end of pipe-from-child
    • When no more to send to child, close write end of pipe-to-child.
    • When all data received, close read end of pipe-from-child.

Note how many closes there are, especially in the child. If you use dup2(), you don't have to close standard input and output explicitly; however, dup() works correctly if you do the explicit closes. Also note that neither dup() nor dup2() closes the file descriptor that is duplicated. If you omit closing the pipes, then neither program can detect EOF correctly; the fact that the current process can still write to a pipe means that there is no EOF on the pipe, and the program will hang indefinitely.

Note that this solution does not alter standard error for the child; it goes to the same place as standard error for the parent. Often, this is correct. If you have a specific requirement that error messages from the child are handled differently, then take appropriate action on the child's standard error too.

Jonathan Leffler
Thanks for the answer.So in theory 2 extra processes are generated for the solution.One for the child and another for the external binary itself.What would be the expected performance hit in this situation?Does a "one process" solution exist? Would anything be gained using such a solution?
Neville Bamshoe
The exec() replaces the forked child. The alternative, avoiding the exec(), is to include the child code in the parent executable. Same plumbing rules apply - just replace the final 'exec' system call with a call to the processing function instead.
Jonathan Leffler
+1  A: 

Depending on your needs, you may find it easier just to use mkfifo(1) to make a named pipe and have your processes read/write to that file. While the file is named in the filesystem, the overhead of using an anonymous pipe shouldn't be appreciable.

Suppressingfire
In the context of the question, there would have to be two separate FIFOs, one for the communication to the child and one for the communication from the child. And you have to worry about concurrent execution of the program - what names are used - and you have to worry about clean up of the FIFOs afterwards (or when the programs crash). Hmmm, what are the advantages of a FIFO?
Jonathan Leffler
That's why I said depending on the needs. Based on the OP's circumstances, it may not be necessary to write any code at all, particularly since he said he wanted to exec(3).
Suppressingfire