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: Bruno Haible
Subject: Re: [Bug-gnulib] addition: pipe.h, pipe-in.c, pipe-out.c, pipe-bidi.c
Date: Fri, 30 Jan 2004 13:05:55 +0100
User-agent: KMail/1.5

Paul Eggert wrote:
> We're talking about different programming models.
> ...
> The Unix way to attack this problem is to have a simple primitive
> fork() ...
>
> 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

This is also the "POSIX way", since the posix_spawn() function provides
exactly this approach.

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.
The 'pipe' module is a help for this class of programs. Less powerful,
but gets the needed functionality in 5 lines of code instead of 100.
If you have another module that can provide a similar help in the remaining
10% or 20% of the cases, you're welcome to add it.

> But I don't see the
> point of converting existing applications to use the Windows way.

Noone has been asking to convert existing applications. Programs that
need the more powerful fork() way, like Apache or tar, shall continue to
use them.

> I don't even see the point of writing new GNU applications to use the
> Windows way.

The fact is that many applications are written this way because it's the
more natural way to think for many programmmers. Why else would have
clisp in 1991 and bison in 2002 and other programs come up with
essentially the same approach? Because the fork()/exec() way is complicated:
dealing with address spaces, efficiency considerations and race conditions
(fork() or vfork()?), file descriptor numbers in different processes, a
complicated control flow, ...
We want something easy to understand: A function call to create the
subprocess, and a function call for the "join".

It's important to make these things easy. One of the basics of Unix -
that make Unix so powerful - is to make many small programs, one for each
purpose, and let them communicate. But if the communication primitive
itself is so hard to grasp and to make use of, many programmers just
create bigger and bigger programs, and the power of Unix gets lost.

That's why I consider the 'execute' and 'pipe' modules as essential for
gnulib.

Bruno





reply via email to

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