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: <1001@bloom-beacon.MIT.EDU>
Date: Wed, 24-Jun-87 23:35:52 EDT
Article-I.D.: bloom-be.1001
Posted: Wed Jun 24 23:35:52 1987
Date-Received: Fri, 26-Jun-87 07:03:33 EDT
References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <1882@ames.arpa> <21928@sun.uucp>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: tytso@athena.mit.edu (Theodore Y. Ts'o)
Organization: Massachusetts Institute of Technology
Lines: 22

In article <21928@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes:
>> Try the built-in command "hashstat" in csh.  It's to be used mostly for
>> debugging, I assume, as it tells you how well the exec hash table is working.
>> The way it counts a "miss" is by incrementing a variable everytime a exec
>> fails.  It has to do this in the child, and thus uses the vfork "shared
>> memory".
>
>It could also do this with a shared file; abusing "vfork"s shared memory
>may have been convenient, but it wasn't necessary.

What about the overhead to update said shared file every time you
execute a command?  I think I prefer the "abuse" of the shared memory.
The main purpose of vfork was to enhance csh's effiency anyway.


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
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.!
                                        |
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+