Newsgroups: comp.unix.wizards
Path: utzoo!lsuc!dave
From: dave@lsuc.uucp (David Sherman)
Subject: Re: pid rollover?
Date: Sun, 29-Jan-89 18:39:26 EST
Summary: it rolls over at 30000
Message-ID: <1989Jan29.183927.26571@lsuc.uucp>
References: <460@oglvee.UUCP>
Organization: Law Society of Upper Canada, Toronto

In article <460@oglvee.UUCP> jr@oglvee.UUCP (Jim Rosenberg) writes:
>Our system is an Altos 2000 running Xenix System V.  The CPU is a 386, and the
>C compiler produces 4 as sizeof(int).  However we seem to be hitting rollover
>of pids at 32K, implying that the kernel must be using short as the type of a
>pid -- at least internally.  I have two questions.  Why wouldn't the kernel use
>a true int for a pid, preventing rollover until 2147483647 or so?  Surely this
>isn't just because someone thought it would louse up the output format of ps??

The rollover has been at 30000 since time immemorial.  On the
16-bit PDP11, where pid was stored in a (short) int, there
obviously would have been a problem after 32767, and I suspect the
original design of a 30000 cutoff was simply to make it easier to
track how many rollovers there had been (they were rare in those
days, remember?).

>As system administrator should I be concerned about letting the pids roll over?
>We've had this happen several times with no apparent ill effects.  I'm not
>concerned about the kernel -- it seems to know what to do when pids roll over.
>But what about all those programs using mktemp() or $$ ?  Does anyone have any
>horror stories about applications that behaved badly after pid rollover?

There's a 1/30000 chance, so it's likely happened somewhere along
the line.  However, it would be hard to spot (imagine guessing at
that as the cause of a bug!), so I doubt too many people will have
had the horror story and have lived to tell of it :-)

David Sherman
-- 
Moderator, mail.yiddish
{ uunet!attcan  att  pyramid!utai  utzoo } !lsuc!dave