Article View: comp.std.unix
Article #694Re: qfork()
From: Donald Lewine
Date: Thu, 27 Dec 1990 14:31
Date: Thu, 27 Dec 1990 14:31
46 lines
2826 bytes
2826 bytes
Submitted-by: lewine@cheshirecat.rtp.dg.com (Donald Lewine)
In article <16213@cs.utexas.edu>, jason@cnd.hp.com (Jason Zions) writes:
|>
|> I think that loosens the restriction too much. The intent of the text, I
|> believe, is that *doing* anything between qfork() and exec*() results in
|> undefined behavior. Checking a variable doesn't *do* anything in this sense.
|> The text tries to sidestep the issue of "is qfork() a 4.2BSD-style
|> share-memory pseudo-fork or is it a real fork or what?" An application which
|> takes an action after qfork() and before exec*() that depends upon the
|> implementation of qfork() being any one of those things is inherently
|> unportable.
|>
|> Instead of replacing "executes any code", I think you could just add the
|> phrase "which modifies memory or calls any function" and maintain the
|> intent. Examining variables doesn't depend upon the virtual memory
|> relationship between child and parent, but munging a stack for a function
|> call might behave differently and hence must be rendered undefined.
|>
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.
(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.]]
As I think about it, (2) is a much nicer solution to the problem
than qfork(). The library can then implement fexecl() as a vfork()
followed by an execl() or a fork() followed by an execl(). The
error handling is clean and the semantics are obvious.
--------------------------------------------------------------------
Donald A. Lewine (508) 870-9008 Voice
Data General Corporation (508) 366-0750 FAX
4400 Computer Drive. MS D112A
Westboro, MA 01580 U.S.A.
uucp: uunet!dg!lewine Internet: lewine@cheshirecat.webo.dg.com
Volume-Number: Volume 22, Number 58
Technical Details
Message-ID:
<16483@cs.utexas.edu>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!jsqReferences:
<16066@cs.utexas.edu> <16213@cs.utexas.edu> <16213@cs.utexas.edu>,Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!jsq From: lewine@cheshirecat.rtp.dg.com (Donald Lewine) Newsgroups: comp.std.unix Subject: Re: qfork() Message-ID: <16483@cs.utexas.edu> Date: 27 Dec 90 14:31:08 GMT References: <16066@cs.utexas.edu> <16213@cs.utexas.edu> <16213@cs.utexas.edu>, Sender: jsq@cs.utexas.edu Reply-To: lewine@dg.uucp Organization: Data General Corporation Lines: 46 Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman) X-Submissions: std-unix@uunet.uu.net