bug-gnulib
[Top][All Lists]
Advanced

[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: 29 Jan 2004 10:54:09 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Bruno Haible <address@hidden> writes:

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

We're talking about different programming models.

The basic problem is that applications have widely varying needs about
what should be done with child processes and their resources.

The Unix way to attack this problem is to have a simple primitive
fork(), where it's the programmer's responsibility to figure out what
to do with the child, using other simple primitives like close() and
execl() that are already available and are useful even to
single-process programs.

What I'm calling the "Windows way" (a bit unfair, since it's not new
or unique to Microsoft Windows) to attack this problem is to have a
complicated process-creation primitive that creates a new process and
specifies lots of things having to with that process (e.g., which
resources it has, what program it runs, etc.).

Both ways work, of course.  They each have their advantages.  However,
most GNU programs are written using the Unix way, for obvious reasons:
they're intended to run on GNU or GNU-like platforms.

The "pipe" module implements the Windows way.  But I don't see the
point of converting existing applications to use the Windows way.  I
don't even see the point of writing new GNU applications to use the
Windows way.  Obviously if you want to port to Windows there are some
advantages to this approach; but that's not a goal of the GNU project.

> More modules in gnulib are welcome, for example one of the 'bitset'
> implementations from bison look like a good candidate.

'bitset' is not in gnulib because only one maintainer uses it.  If
other maintainers see an interest in it then it should probably get
moved into gnulib; otherwise it's not worth the hassle.  GCC is the
next obvious candidate for bitset, but the GCC folks haven't moved on
this issue for many months despite someone contributing patches along
those lines.  (bitset was originally contributed to GCC, not to
Bison.)

> I'm quite confident that more programs will use it

Perhaps you're right, but maybe not.  In the meantime, what's the rush?

> other modules (physmem, idcache, userspec, xgetdomainnname etc.) are
> more rarely used than 'pipe'.

Yes, there's probably other junk in gnulib too.  At some point someone
should do some housecleaning.  Or reorganization.  Or something.
Gnulib is becoming a bit unwieldy.  (For example, I'd like to put
almost all the "windows stuff" off into a separate subdirectory so I
don't have to read it.  :-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]