Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!haven.umd.edu!umd5!cogsci!wjb
From: wjb@cogsci.cog.jhu.edu (Bill Bogstad)
Newsgroups: comp.benchmarks
Subject: Re: Which benchmarks are useless?
Message-ID: <03.May.91.174910.55@cogsci.cog.jhu.edu>
Date: 3 May 91 21:49:10 GMT
References: <21720006@hpfcso.FC.HP.COM> <02.May.91.132611.54@cogsci.cog.jhu.edu> <MEISSNER.91May3135345@curley.osf.org>
Organization: JHU Cognitive Science Center, Baltimore, MD
Lines: 24

In article <MEISSNER.91May3135345@curley.osf.org>
meissner@osf.org (Michael Meissner) writes:
>>[I (Bill Bogstad wrote about timing getppid() vs. getpid()]

>But of course if you fork (), your pid also changes......

	Only sort of.  The parents PID doesn't change.  The child just gets a
new one.

	The idea behind this micro benchmark was to measure the overhead of
a system call.  The getpid() and getppid() calls don't do any significant
work in the kernel and therefore would appear to be a good choice for
measuring this.  The problem is that getpid() COULD be written to cache the
PID since it only changes when you do a fork() (under the control of the
program itself).  A PID cache would work in the presence of fork() by having
the fork() run time library invalidate the PID cache within the context of
the process.  The parent process ID of a process can change completely
asynchronously with respect to the process itself.  There is no way for a
cache of the PPID to be maintained in the programs dataspace without
reference to information that only the kernel knows about.  You would have
to use something like a shared page of memory which the kernel sets and the
process reads.  (As mentioned in my last message.)

				Bill Bogstad