Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/v22/060

Internet Message Format | 1991-03-07 | 4KB

From [e-mail]  Fri Jan  4 19:14:21 1991
Received: from CS.UTEXAS.EDU by uunet.UU.NET (5.61/1.14) with SMTP
    id AA25939; Fri, 4 Jan 91 19:14:21 -0500
Posted-Date: 4 Jan 91 18:26:34 GMT
Received: by cs.utexas.edu (5.64/1.92)
From: [e-mail] (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Standard Answer Ltd.
X-Submissions: [e-mail]
Date: 4 Jan 91 18:26:34 GMT
To: [e-mail]

Submitted-by: [e-mail] (Dominic Dunlop)

In article <[e-mail]> [e-mail] (Donald Lewine) writes:

>     I think I would vote "NO" on qfork().  I think that there are
>     two better solutions:
>     (1) Just use fork() and require the implementation to do it
>         in an efficient manner.

Well, I know that we POSIX folks want to rule the world, but just how
ugly a world will we put up with in order that we can rule it?  qfork()
(and vfork()) special-case a particular usage of the process creation
mechanism in order to give implementors an easier time of it.  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.

That said, POSIX has nothing to say about the efficiency of any
particular implementation: that's a quality issue, not a conformance
issue.  One hopes that in the kind of free market that standards are
supposed to encourage, better quality will win out over poorer quality,
other things being equal.  So, yes, I'm in favour of keeping just
fork(), and letting implementors worry about how slick they need to make
it.  After all, there's few implementors in this world than applications
programmers, so it seems to make sense to localize the pain involved to
the smaller group.  Sorry about that.  I am aware that the efficient
implementation of fork() is a real headache on some architectures, and
particularly in hosted POSIX, but, well, so's cooking up fake inodes
(or parts thereof).  Happily, I hear nobody suggesting that we define
unsafe versions of stat() to get around that problem.  Just how far
should we bend over backwards to accommodate history?  Remember that
every extra function we define has to be maintained on all
implementations for ever more (more or less), and that every extra
function is something else that programmers have to learn about.

>     (2) Add some new functions (fexec() ?) which do the fork() and
>         exec() in one call.  I know that this is not existing practice
>         but neither was sigemptyset() or tcgetispeed().  This may be
>         another case where it is better to define a new interface than
>         to try to describe the existing practice.  [[Also, qfork() is
>         not quite vfork() so it can be shot down on the same basis.]]

I don't like this much either, but it might be an acceptable compromise
if the effect of the new functions was defined in the standard in terms
of fork() and exec() family functions.  This would make it easy to bring
existing implementations with an efficient fork() into line.  Please
let's resist the temptation to add new functionality to exec (for
example) on the way past.

By the way, what line (if any) are the .5 (Ada) folks taking on this
issue?  How does all this square (if at all) with Ada's concept of a
task?
--
Dominic Dunlop

Volume-Number: Volume 22, Number 60