🚀 go-pugleaf

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