Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!apple!sun-barr!ccut!titcca!cc.titech.ac.jp!necom830!mohta From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta) Newsgroups: comp.arch Subject: Re: vfork (was Re: Paging page tables) Message-ID: <5896@titcce.cc.titech.ac.jp> Date: 19 Jul 90 08:15:14 GMT References: <920@dgis.dtic.dla.mil> <5830@titcce.cc.titech.ac.jp> <2340@root44.co.uk> Sender: news@cc.titech.ac.jp Organization: Tokyo Institute of Technology Lines: 27 In article <2340@root44.co.uk> jgh@root.co.uk (Jeremy G Harris) writes: >With all this discussion of possible modifications to Unix semantics, I >just have to put my oar in. I hope I won't annoy anyone too much. >Proposal: A segment type which is _lost_ by the child of a fork. The proposal should be replaced with a more general one which can specify various segment type such as LOST, READONLY_SHARED, COW, READWRITE_SHARED and so on. So, there will be a new scntl (segment control) system call just like fcntl. Anyway, to replace vfork, just LOST is not sufficient. So, suppose, scntl system call is introduced, the most typical use of it is replacement of vfork. Moreover, it is complex to write forking code from the scratch. So, vfork will survive as a library function. Anyone remember an arcane system call "creat"? It is still a handy function to create files. Certainly, you can do it only with open, but it is error prone. > 5) Source modifications to existing programs are required. No. Only a status of vfork will change. Masataka Ohta