Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!jsq From: marc@arnor.uucp Newsgroups: comp.std.unix Subject: Re: qfork() Message-ID: <16284@cs.utexas.edu> Date: 28 Dec 90 14:24:10 GMT References: <16066@cs.utexas.edu> <16213@cs.utexas.edu> <16245@cs.utexas.edu> Sender: jsq@cs.utexas.edu Organization: IBM T.J. Watson Research Center, Hawthorne, New York Lines: 26 Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman) X-Submissions: std-unix@uunet.uu.net Submitted-by: marc@arnor.uucp It would be useful to know why the function is being proposed. One assumes an efficiency improvement, which implies that the specifiers have an implementation in mind. 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? 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? -- Marc Auslander Volume-Number: Volume 22, Number 44