Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!killer!vector!rpp386!jfh
From: jfh@rpp386.Dallas.TX.US (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: pid rollover?
Summary: i ain't gonna use no goto's
Message-ID: <12118@rpp386.Dallas.TX.US>
Date: 1 Feb 89 07:34:50 GMT
References: <460@oglvee.UUCP> <1800007@spdyne> <923@auspex.UUCP>
Reply-To: jfh@rpp386.Dallas.TX.US (John F. Haugh II)
Organization: River Parishes Programming, Dallas TX
Lines: 32

In article <923@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
>And it doesn't on his (S5?) system.  Different systems do it
>differently.  (Actually, the S5R3 code sets "nextpid" - actually, "mpid"
>- to 0, but if process ID 0 isn't already in use something rather
>strange has happened on your system....)

The general effect of the entire ordeal is something like

	struct	proc	*pp;

again:
	if (++mpid == MAXPID) {
		mpid = 0;
		goto again;
	}
	for (pp = proc;pp < v.ve_proc;pp++)
		if (pp->p_stat && pp->p_pid == mpid)	/* oops, exists */
			goto again;

The kernel repeatedly scans for a valid pid.  So the concern over
conflicting pid's is unfounded.  There is much more involved as
well.  Unless Guy wants to post the source to newproc(), I think
this is sufficient detail to answer the original question.

Of course, with school back in session, you really didn't expect
me to go posting code with a goto in it ;-)  See what you made me
do? ;-)
-- 
John F. Haugh II                        +-Ad of the Week:----------------------
VoiceNet: (214) 250-3311   Data: -6272  |"Your hole is our goal"
InterNet: jfh@rpp386.Dallas.TX.US       |     -- Gearhart Wireline Services
UucpNet : <backbone>!killer!rpp386!jfh  +------  Shrevesport, LA  -------------