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

[Bruno Haible]

Paul Eggert wrote:
> I'd say that the main point of gnulib is more to provide commonly used
> and needed functionality.

It is commonly used functionality. Communicating with subprocesses via
pipes is needed in
  - gettext (10 x create_pipe_in, 3 x create_pipe_out, 1 x create_pipe_bidi),
  - clisp (1 x create_pipe_in, 1 x create_pipe_out, 1 x create_pipe_bidi),
  - bison (1 x create_pipe_bidi),
  - cvs (1 x create_pipe_bidi),
  - tar (1 x create_pipe_in, 1 x create_pipe_out, for the compressor)
  - rmt (1 x create_pipe_bidi).

> Portability to non-POSIX systems is nice if
> it's very easy to add, but it's not a main goal.

That's why I mentioned the three other features of the module:

  - 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.

In bison, you need 100 lines of code, just for the first two features
(ease of use and error handling). This shows that there is a need for
this functionality.

> I think part of my problem with the proposed 'pipe' module is
> basically that it takes the Windows model, since that can be
> implemented efficiently on both Windows and POSIX.

I don't deny that some programs may make good use of pipes without exec(),
for example 'tar' when it forks, or Apache. But 80% or 90% of
the uses of pipe() are in combination of fork+exec, and the 'pipe'
module provides a handy way to get it - without going through the
low-level details of which pipe()d file descriptor must be closed at
which moment etc.

> Not that I'm saying that the Bison pipe code is perfect for everybody!
> It's fine for Bison but I don't know of any other code that needs it.

The bison code shows well why gnulib/pipe is needed: 100 lines of code,
implementing roughly the same thing as dozens of other programs, but
it is still not usable by other programs because the code is not flexible
enough: it treats only the bidirectional case, doesn't reap the subprocess
automatically, cannot redirect stderr to /dev/null, cannot report errors
of the subprocess through an error indicator.

> That's why I haven't proposed that code for gnulib, even though it's
> stable, been used for some time, etc.

More modules in gnulib are welcome, for example one of the 'bitset'
implementations from bison look like a good candidate. It's a generally
useful datastructure like 'obstack' and 'hash'.

> How about if we wait for two different maintainers to use the pipe
> module first, before putting it into gnulib? I don't much see the
> point of having this module in gnulib if only one maintainer is likely
> to use it.

I'm quite confident that more programs will use it, therefore I see no
point in delaying it. Your argumentation is quite strange; IMO other modules
(physmem, idcache, userspec, xgetdomainnname etc.) are more rarely used
than 'pipe'.

Bruno