M> The library functions which are included to allow process
M> launch, forking, and termination, imply that it is both
M> possible and desirable for a process to fork itself. This
M> is a fundamental part of the Unix thought process, but is
M> not essential for a working OS.

RP> How do you intend for users to run programs?  You'd
RP> still need to allow process launch and termination, even
RP> if you eliminated forking.  [...]

Note that what Matt wrote was confused.  Forking _is_ process
launching.  It is how one creates a new process.  The phrase "launch,
forking, and termination" is like the phrase "glucose and sugar" used
in Mars Bar advertisements in some countries during the 20th century,
which at least one chemist used to translate to "sugar and more
sugar".  The correct third action, to group with forking and
termination, is program image overlay -- i.e. execve().

[ Post a follow-up to this message ]

On Wed, 19 Sep 2007 05:53:26 -0700, J de Boyne Pollard wrote:

> M> The library functions which are included to allow process M> launch,
> forking, and termination, imply that it is both M> possible and
> desirable for a process to fork itself. This M> is a fundamental part of
> the Unix thought process, but is M> not essential for a working OS.
>
> RP> How do you intend for users to run programs?  You'd RP> still need
> to allow process launch and termination, even RP> if you eliminated
> forking.  [...]
>
> Note that what Matt wrote was confused.  Forking _is_ process launching.
>  It is how one creates a new process.

Fork() is, I believe, a unix invention. I have worked on OSs which
did not require fork(), some of which OSs did not implement fork().
For some process and executable implementations it is trivial to
create a process starting at a specified instruction or with a
specified executable, and non-trivial to impossible to create a
process that shares or copies the state of a running process.

<OT>
I have also worked on an OS which, on boot, fully populated its
(fixed size) task table with running processes, most of which
rapidly entered some wait-for-event state. "Launching" a process
required acquiring one of the active-but-unallocated processes
and modifying its top-of-stack to goto the desired instruction.
I strongly doubt that there has ever been a C compiler for such
an OS.
</OT>

Martin
--
Martin Golding DoD #0236 | fogobum@comcast.net
Always code as if the person who ends up maintaining your code will be a
violent psychopath who knows where you live.

[ Post a follow-up to this message ]

Martin Golding <fogobum@comcast.net> writes:
> On Wed, 19 Sep 2007 05:53:26 -0700, J de Boyne Pollard wrote: 
>
> Fork() is, I believe, a unix invention.

That doesn't make it any more sensible to include both 'process launching'
and 'forking' in a list of primitives.

[ Post a follow-up to this message ]

"J de Boyne Pollard" <j.deboynepollard@tesco.net> wrote in message
news:1190206406.960518.260140@r29g2000hsg.googlegroups.com...
> M> The library functions which are included to allow process
> M> launch, forking, and termination, imply that it is both
> M> possible and desirable for a process to fork itself. This
> M> is a fundamental part of the Unix thought process, but is
> M> not essential for a working OS.
>
> RP> How do you intend for users to run programs?  You'd
> RP> still need to allow process launch and termination, even
> RP> if you eliminated forking.  [...]
>
> Note that what Matt wrote was confused.  Forking _is_ process
> launching.  It is how one creates a new process.

I understood his mention of forking to be one user process creating another
user process.  Whereas, I understood process launch and termination as the
OS creating and destroying a user process.  Depending on the OS
implementation these may be indentical or different or non-existent in part
or full.


Rod Pemberton

[ Post a follow-up to this message ]

[removed f'up to clc, I can't see what this have to do with C]
On Wed, 19 Sep 2007 05:53:26 -0700, J de Boyne Pollard wrote:
> Note that what Matt wrote was confused.  Forking _is_ process
> launching.  It is how one creates a new process.  The phrase "launch,
> forking, and termination" is like the phrase "glucose and sugar" used
> in Mars Bar advertisements in some countries during the 20th century,
> which at least one chemist used to translate to "sugar and more
> sugar".  The correct third action, to group with forking and
> termination, is program image overlay -- i.e. execve().
On some OSes, you can create a new process which is not a copy of
an existing one, much like sucrose is a sugar which is not
glucose.
--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes” feature. This is so you'll avoid sprinkling garbag
e
characters through your mail. -- Eric S. Raymond and Rick Moen

[ Post a follow-up to this message ]

Martin Golding wrote:
> On Wed, 19 Sep 2007 05:53:26 -0700, J de Boyne Pollard wrote:
> 
>
> Fork() is, I believe, a unix invention. I have worked on OSs which
> did not require fork(), some of which OSs did not implement fork().
> For some process and executable implementations it is trivial to
> create a process starting at a specified instruction or with a
> specified executable, and non-trivial to impossible to create a
> process that shares or copies the state of a running process.

The above messing up of the previous quotations is a sufficient
reason to avoid non-standard quotation markings.  M. Pollard should
take note.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

[ Post a follow-up to this message ]

[comp.lang.c removed since it is irrelevant]

In article <pan.2007.09.19.16.26.38@comcast.net>
Martin Golding  <fogobum@comcast.net> wrote:
>Fork() is, I believe, a unix invention.

Actually, it was taken from an even earlier system on the SDS Sigma.
See <http://cm.bell-labs.com/cm/cs/who/dmr/hist.html>.

Many OSes have a combined "fork and exec" primitive, often called
"spawn" (or some variant of that name).  One big argument for this is
efficiency: a typical Unix-like process sequence is:

pid = fork();
if (pid == 0) {
.. do some setup work ...
execve(path, argv, env);
_exit(CODE);
}

and depending on the "setup work" involved, a single call like:

pid = spawnve(path, argv, env, SETUP_WORK_FLAGS);

is obviously "more efficient": here, we need not duplicate the
entire original process just to throw it away and replace it with
the new image.

The problem is that the "setup work" can be, and -- at least
surprisingly often -- actually turns out to be, "arbitrarily
complicated".  The OS that lacks fork() forces this work to be
encoded in an argument to spawnve().  This winds up being too
restrictive, and eventually, such systems often acquire a primitive
more or less equivalent to fork() after all. :-)

(An alternative solution is to provide actual code, rather than
just flags, to the spawn call.  This method depends on a number of
other system features, such as security enforcement mechanisms and
perhaps relocatable code.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40�39.22'N, 111�50.29'W)  +1 801 277 2603
email: forget about it   http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[ Post a follow-up to this message ]

Martin Golding <fogobum@comcast.net> writes:
>On Wed, 19 Sep 2007 05:53:26 -0700, J de Boyne Pollard wrote:
> 
>
>Fork() is, I believe, a unix invention. I have worked on OSs which
>did not require fork(), some of which OSs did not implement fork().

Tell that to the Burroughs B-5500 engineers.  The routine in the
Master Control Program (MCP) to create a new task/process was called
"motherforker".   This predated unix.

scott

[ Post a follow-up to this message ]