[svlug] Reuse of pid's.

Karen Shaeffer shaeffer at neuralscape.com
Thu Jan 22 22:19:34 PST 2009


On Thu, Jan 22, 2009 at 12:05:20AM -0800, Bill Ward wrote:
> On Wed, Jan 21, 2009 at 9:05 PM, Karen Shaeffer
> <shaeffer at neuralscape.com> wrote:
> > On Wed, Jan 21, 2009 at 01:33:32PM -0800, Bill Ward wrote:
> >>
> >> Right, and so if you have process creation happening that fast, such
> >> that a PID which was recently freed is already to be used again,
> >> you've got bigger problems than this.
> >
> > Hi,
> > Consider a process that the kernel launches with a new pid. Assume
> > this process persists for a long time. The kernel will continue to
> > issue new pid's that are greater than our hypothetical process's pid.
> > And the kernel will eventually wrap back to the very low pids and start
> > ascending the pid list again. And eventually the kernel will be issuing
> > new pid's that are close to our hypothetical process's pid but less than
> > it. And if you kill our hypothetical process at this moment, then the
> > kernel may very well re-issue that pid very soon after it was freed.
> 
> Does it do them in numerical order, or does it maintain a queue of the
> released ID's?  I thought the latter.

Hi Bill,
There is no queue. The kernel saves the value of the last pid allocated,
and increases from there looking for the next pid. When it rolls over, it
cycles through the list again, and again. The base structure for the pidmap
is a bitmap. Set the bit, and the pid is in use. Clear it when the pid is
freed. There is no state information about the history of a recently freed
pid. In newer kernels, once a pid is put into service, then it is wrapped up
into an elaborate set of structures segmented by namespace and accessed by
hash tables intended to facilitate efficiency while the process lives. There
is no consideration given to how pids are used in userspace at any time in
the life cycle of pids.

Thanks,
Karen
-- 
 Karen Shaeffer
 Neuralscape, Palo Alto, Ca. 94306
 shaeffer at neuralscape.com  http://www.neuralscape.com




More information about the svlug mailing list