Date: Fri, 1 Sep 1995 18:45:00 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: 16-bit pids? (was Re: 16, 32, and 64bit types?) Message-ID: <199509011645.SAA16004@uriah.heep.sax.de> In-Reply-To: <Pine.BSI.3.91.950901212739.21658E-100000@aries> from "Brian Tao" at Sep 1, 95 09:29:59 pm
next in thread | previous in thread | raw e-mail | index | archive | help
As Brian Tao wrote: > > On Thu, 31 Aug 1995, J Wunsch wrote: > > > > That's not the problem. The actual problem are long-living processes > > that cause collisions since you expect temp files like > > /foo/bar/file.<pid> to be unique within the system. > > Why would a collision occur? If you have along-living process at, > say, pid 151 (like what 'xdm' is on my machine right now) and the most > recently used pid was 150 (assuming it had cycled around), wouldn't > the scheduler/kernel just see that 151 is still running, and number > the next process 152? Is that the type of "PID collision" you are > referring to? Nope, the long-living processes have been a poor example. The problem rather occurs whenever you've got some PID file around and are not sure whether this is the leftover of a previously aborted process or the process is actually still alive. These da*n tty lockfiles are a good example. Since nobody can be sure that a lock file lurking around does actually belong to a live process, everybody who's dealing with those files is examining it first, and attempts to send that process a signal. If this is yielding anything else than `ESRCH', the process is considered to be still active, hence the lock is valid and remains untouched. (Otherwise, the new program will remove the lock file and create one of its own.) After a PID rollover, the non-uniqueness of the PID namespace can fool this mechanism. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509011645.SAA16004>