Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!jsq
From: jason@cnd.hp.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: qfork()
Message-ID: <16372@cs.utexas.edu>
Date: 31 Dec 90 17:39:01 GMT
References: <16243@cs.utexas.edu> <16244@cs.utexas.edu> <16245@cs.utexas.edu> <16271@cs.utexas.edu> <16284@cs.utexas.edu> <16307@cs.utexas.edu> <16369@cs.utexas.edu> <16370@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Organization: Hewlett Packard, Information Networks Group
Lines: 28
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: jason@cnd.hp.com (Jason Zions)

>Also, it should be remembered that unix systems don't execute C - they
>execute machine instructions generated by the C compiler.  So it is
>necessary to specify the behavior in machine terms if the compiler
>writers are going to comply.  In particular, there is nothing to
>prevent the compiler from moving certain computations to the space
>between the qfork and the exec!  Does a compiler need to recognize
>qfork and exec as special?

That's specious. Of *course* the compiler needs to recognize system calls as
sync points. It wouldn't do for the compiler to migrate the instructions
which initialize a write() buffer to after the write() call, would it?

>Finally - if the intent is to "bundle" fork and exec together,
>assuming only that the fork succeeds, would it not be better to
>propose fexec* - a set of exec calls which fork first?  Of course,
>this makes it absolutely clear that nothing can happen between fork
>and exec.  If the combined function is then deemed useless, how can
>the qfork/exec idiom be better?

Um, how about "existing practice"? More than that, there's a whole raft of
common extensions revolving around various forms of qfork() that many would
like to see remain as possible extensions.

Jazz

Volume-Number: Volume 22, Number 50