[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnulib] addition: pipe.h, pipe-in.c, pipe-out.c, pipe-bidi.c
From: |
Paul Eggert |
Subject: |
Re: [Bug-gnulib] addition: pipe.h, pipe-in.c, pipe-out.c, pipe-bidi.c |
Date: |
31 Jan 2004 23:01:39 -0800 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 |
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.