Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!rutgers!cmcl2!edler
From: edler@cmcl2.NYU.EDU (Jan Edler)
Newsgroups: comp.unix.wizards
Subject: Re: pid rollover?
Summary: immediate reuse of pids can cause problems
Message-ID: <37388@cmcl2.NYU.EDU>
Date: 8 Feb 89 19:34:41 GMT
References: <460@oglvee.UUCP> <1800007@spdyne> <923@auspex.UUCP> <1043@vsi.COM>
Reply-To: edler@nyu.edu (Jan Edler)
Organization: New York University, Ultracomputer project
Lines: 46

In article <1043@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes:
>Please note that PIDs are not necessarily monotonically
>increasing on all systems.  On the AT&T 3B15 (the master CPU for
>the multiprocessor 3B4000) the PIDs jump all over the place.  For
>example, a trivial program to fork 20 times prints PIDs in the
>following order:
>
>12331 12331 8236 12331 8236 16397 12331 8236 16397 20535
>12331 8236 16397 20535 28918 12331 8236 16397 20535 28918
>
>Note the reassignment of old PIDs here.  You have to look
>at the PIDs in hex to get any kind of pattern, and it probably
>reflects processor assignment or some such.

I find this surprising.  I claim that an implicit assumption prevails
in conventional UNIX usage, against immediate reuse of pids.  There are
many cases where such immediate reuse can lead to problems.  A simple
example is a background process that you want to kill.  So you send it
a signal, but in the meantime it already terminated and another process
inherited the pid.  If the new process belongs to someone else, it may
not matter (unless you are root!), but it could just as easily be
yours, and you'll end up hitting the wrong process.

In fact, this problem exists in all UNIX's I'm familiar with: it is
possible (but probably rare) for a pid to be reused immediately.  This
possibility is generally ignored.  Has it ever bitten anyone?  Who knows?

I don't see any way to reliably use pids (or any other names within a
limited namespace) without some kind of assurance against immediate
reuse (except for the use of comparing the return value of fork against
the return value of wait).  Even with such an assumption, how long must
the prohibition on reuse last?  I don't know the answer to this, but in
practice the pid space needs to be large enough that reuse isn't likely
to be "soon".

If such an assumption were not needed, we might as well limit the pid
space to the maximum number of concurrently active processes, NPROC,
typically only a few hundred or thousand.  In fact, in conventional
implementations, we could just let the pid be the index into the proc
table.

Jan Edler
NYU Ultracomputer Research Laboratory
edler@nyu.edu
...!cmcl2!edler
(212) 998-3353