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

[Paul Eggert]

Bruno Haible <address@hidden> writes:

> Yes these are different programming models, and 80% or 90% of the programs
> need only the posix_spawn() way, not the more powerful fork()/exec() way.

posix_spawn is indeed weaker, but it's not simpler overall.
posix_spawn attempts to package up many of the things a child process
is likely to do between a fork and an exec (e.g., 'close'), using a
tricky interface that I'd guess not 1 in 100 GNU programmers knows
about in detail.

posix_spawn is not really designed as a replacement for fork/exec.
It's designed to allow hardware lacking swapping and/or dynamic
address translation.  Such hardware is not a principal goal of the GNU
project, and I'd rather not worry about it.

I understand that 'pipe' attempts to simplify this, and come up with a
nicer interface suitable to many GNU programs.  But I'm skeptical that
the simplification will really work all that well in practice.  The
resulting interface still has the "feel" of posix_spawn, and I think
it's likely to suffer from similar deficiencies.

All this being said, if you've really found this module useful in lots
of gettext programs, then I suppose it won't harm things to put it
into gnulib.  So I withdraw my objection to this change.  However, I
don't want to have a lot of other modules start depending on it,
because this module is "controversial" (in the sense described above)
and we don't want to insist on every program using it.


> Why else would have clisp in 1991 and bison in 2002 and other
> programs come up with essentially the same approach?

They're not really the same approach.  The Bison approach is quite
simple and is designed for a special case; it undoubtedly wouldn't
work for clisp.  I suspect (though I haven't looked into it) that the
clisp approach would not work for Bison as efficiently as the Bison
approach does.