[comp.unix.questions] The trouble with fork

peter@ficc.uu.net (Peter da Silva) (01/17/90)

Fork() is an elegant concept, but as has been seen it leads to problems
implementing UNIX on a system without an MMU, or implementing a UNIX
lookalike on top of a non-UNIX O/S. It's possible, but expensive.

Wouldn't it be nice if there was a sanctioned P1003 subset that replaced
fork() with a combined fork()/exec() call (spawn?). Or just an addition
of spawn to the standard as an alternative process creation mechanism:
This would radically improve the performance of non-UNIX POSIX systems,
without compromising the capability of the standard...
-- 
 _--_|\  Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/      \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
      v  "Have you hugged your wolf today?" `-_-'

gwyn@smoke.BRL.MIL (Doug Gwyn) (01/17/90)

In article <DW31DR7xds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>Wouldn't it be nice if there was a sanctioned P1003 subset that replaced
>fork() with a combined fork()/exec() call (spawn?). Or just an addition
>of spawn to the standard as an alternative process creation mechanism:
>This would radically improve the performance of non-UNIX POSIX systems,
>without compromising the capability of the standard...

Wrong; fork() is more flexible than spawn(), and this is thoroughly
exploited by UNIX applications.  For example, a job control shell
has many things to do between the fork() and the exec() in the child
branch.

IEEE P1003 decided early on not to compromise UNIX semantics merely
to allow POSIX to be more readily implemented on non-UNIX platforms.

peter@ficc.uu.net (Peter da Silva) (01/18/90)

In article <11969@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
> In article <DW31DR7xds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
> >Wouldn't it be nice if there was a sanctioned P1003 subset that replaced
> >fork() with a combined fork()/exec() call (spawn?). Or just an addition
                                                       ^^^^^^^^^^^^^^^^^^^
> >of spawn to the standard as an alternative process creation mechanism:
   ^^^^^^^^                 ^^^^^^^^^^^^^^^^^
> >This would radically improve the performance of non-UNIX POSIX systems,
> >without compromising the capability of the standard...

> Wrong; fork() is more flexible than spawn(), and this is thoroughly
> exploited by UNIX applications.

Read my lips: no new taxes.

Oops. Wrong program.

Anyway, look at the second sentence above. Most cases of fork/exec could
be replaced by a simple spawn call, making the majority of programs that
didn't need fork/exec more efficient.

How do you feel about adding coroutines to C?
-- 
 _--_|\  Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/      \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
      v  "Have you hugged your wolf today?" `-_-'