Date: Tue, 10 Jun 1997 11:25:34 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "Peter J. Farley III" <pjfarley AT dorsai DOT org>
cc: djgpp AT delorie DOT com
Subject: Re: Why not fork() etc. specific for for shell usage?
In-Reply-To: <339cab1d.4634824@news.dorsai.org>
Message-ID: <Pine.SUN.3.91.970610112455.3067Y-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Tue, 10 Jun 1997, Peter J. Farley III wrote:

> What I was trying to get to, I think,
> was at least simulated tasking support, with the idea that other unix
> ports that *require* some kind of fork() facility would both compile
> and execute, *thinking* they had a "real" fork(), even if they did
> not,

Actually, this might be a welcome addition to the library, since it
makes porting job easier.  Usually, any program that pulls the usual
Unix fork/exec trick needs this part to be #ifdef'ed away and replaced
with code that calls `spawnXX' functions, even if the parent just
waits for the child to finish.  A working `fork' will make this much
easier.  But please note that, due to peculiarities of the fork/exec
paradigm, it is not trivial to write such a version of `fork'.  You
will need some behind-the-scenes cooperation between the functions
that are involved in this plot (`fork', `exec', `pipe', and `wait'),
to make it work without requiring source-level changes to the
application code.