Path: utzoo!censor!geac!torsqnt!hybrid!scifi!bywater!uunet!cs.utexas.edu!jsq
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-ID: <16873@cs.utexas.edu>
Date: 7 Jan 91 04:21:51 GMT
References: <16213@cs.utexas.edu> <16483@cs.utexas.edu> <16522@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Organization: Tokyo Institute of Technology
Lines: 32
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)

>By now we
>know that in a ``from to ground up'' virtual memory implementation of
>UNI*X with a half-way useful memory management hardware copy on write and
>similar finessing can make the general-case fork() call as efficient as
>any special-case variant, and, unlike the variants, is free from any
>threat that sixteen ton weights will be dropped on any programmer who
>steps out of line.

You should also know that copy-on-write fork(), unlike vfork(), is inherently
buggy and can not be a general-purpose useful memory management mechanism.

If you have 50MB swap space and want to fork() 30MB process to exec less
than 1MB shell, you can't. With COW fork(), there is workaround. But the
workaround is so incomplete that the system sometimes deadlocks.

Thus, fork(), even COW fork(), is not a proper mechanism to fork-exec
other processes.

If you insist on using fork(), someday, thirtytwo ton weights will drop on
your head.

						Masataka Ohta

PS

I can't understand why the name vfork() is changed to qfork(). On crippled
systems which can not support true vfork(), the implementors can make vfork()
just fork(). It is actually done on NeXT. What's wrong with that?

Volume-Number: Volume 22, Number 64