qfork()
Jason Zions
jason at cnd.hp.com
Tue Jan 1 04:39:01 AEST 1991
Submitted-by: jason at 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
More information about the Comp.std.unix
mailing list