Path: 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

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