Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!bloom-beacon!tytso From: tytso@athena.mit.edu (Theodore Y. Ts'o) Newsgroups: comp.unix.questions Subject: Re: Fork and Join, Pipe in C Message-ID: <1006@bloom-beacon.MIT.EDU> Date: Thu, 25-Jun-87 18:42:00 EDT Article-I.D.: bloom-be.1006 Posted: Thu Jun 25 18:42:00 1987 Date-Received: Sat, 27-Jun-87 03:50:24 EDT References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <1001@bloom-beacon.MIT.EDU> <22057@sun.uucp> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: tytso@athena.mit.edu (Theodore Y. Ts'o) Organization: Massachusetts Institute of Technology Lines: 47 In article <22057@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >> I think I prefer the "abuse" of the shared memory. > >I hope you also prefer explaining to somebody why the function that >abuses "vfork" mysteriously fails under 4.nBSD, for some n > 3, or on >some box with a VM system that uses copy-on-write and thus implements >"vfork" as an alias for "fork" - and do so with NO complaints about >such implementations, as those complaints are completely unjustified. For some n>3, /bin/csh will presumably be updated when vfork changes. If some VM system implements a copy-on-write fork and changes vfork on NOW, they will break csh. >I quote from the 4.3BSD manual page for "vfork": > > This system call will be eliminated when proper system sharing > mechanisms are implemented. Users should not depend on the memory ^^^^^ > sharing semantics of "vfork" as it will, in that case, be made > synonymous to "fork". > /bin/csh is a system program. USERS can write such programs at their own risk. >> The main purpose of vfork was to enhance csh's effiency anyway. > >Yes, but the efficiency improvement due to eliminating a copy of the >entire data and stack segment was large; I've seen no evidence that >there would be any major efficiency improvement due to abusing >"vfork". We're talking about a very small amount of data here (it >should fit into one frag), and that data is modified only if an >"exec" fails. "exec"s shouldn't fail, in general, especially given >the C shell's path hashing. A hashstat on my workstaion shows 26%. Other hosts that I'm logged into show hit ratios of about 40%. Our environment requires relatively long search paths. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Theodore Ts'o | mit-eddie!mit-athena!tytso | M.I.T., tytso@athena.mit.edu | P.h.D., 3 Ames St., Cambridge, MA 02139 | M.O.N.E.Y.! | =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+