Re: [Bug-gnulib] addition: pipe.h, pipe-in.c, pipe-out.c, pipe-bidi.c

[Bruno Haible]

Paul Eggert wrote:
> I'm not sure it's needed in gnulib.

The functionality that this module brings over fork/exec is:
  - portability,
  - ease of use: just two function calls for each situation,
    create_pipe_...() at the beginning and wait_subprocess() at the end.
  - built-in error handling,
  - automatic reaping of slave subprocesses.

Let's take an example, directly from GNU msggrep. These ten lines of
code run a 'grep' subprocess with given arguments on a given string.


      pid_t child;
      int fd[1];
      int exitstatus;

      /* Open a pipe to a grep subprocess.  */
      child = create_pipe_out ("grep", grep_path, grep_argv[grep_pass],
                               DEV_NULL, false, true, true, fd);

      if (full_write (fd[0], str, len) < len)
        error (EXIT_FAILURE, errno,
               _("write to grep subprocess failed"));

      close (fd[0]);

      /* Remove zombie process from process list, and retrieve exit status.  */
      exitstatus = wait_subprocess (child, "grep", false, false, true, true);
      return (exitstatus == 0);


Don't tell me that you can do the same thing with the same reliability
with fork/exec in ten lines of code!

> It won't suffice for diffutils, for the hairy signal-handling reasons
> we talked about earlier.

Agreed. Although the three modules 'wait-process', 'execute', 'pipe' now
support most of the features that were mentioned in the thread of
http://mail.gnu.org/archive/html/bug-gnulib/2003-09/msg00263.html,
the 'sdiff' programs does them with a little more perfection - at the cost
of needing special EINTR treatment:
  - To guarantee that no CPU time is unnecessarily burned after one of two
    processes has exited.
  - To guarantee that killing the subprocess will not kill an unrelated
    process in some extremely rare situation involving a race condition
    (that waitid() was designed to fix, but waitid() doesn't work).

> I suspect Bison wouldn't need it either, as Bison has simple needs
> (create a subfilter, that is guaranteed to not output anything until
> it's read all its input)

This is a perfect use case for create_pipe_bidi().

And the run_exec function in cvs-1.12.

And the create_input_pipe/create_output_pipe functions in GNU clisp.

And some more, I think.

> that are more easily satisfied by invoking the POSIX primitives directly.

The point of gnulib as a portability library is to make it work on systems
which don't have the POSIX primitives. Like Windows for example. If we
could assume POSIX, we wouldn't need half of gnulib!

> So (as they say in business :-) who's the customer, other than gettext
> itself?

Anything else that needs to run a subprocess and communicate with it.
There's a lot of it in Unix.

Bruno