From owner-freebsd-hackers Fri Sep 1 10:37:31 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id KAA11003 for hackers-outgoing; Fri, 1 Sep 1995 10:37:31 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id KAA10997 for ; Fri, 1 Sep 1995 10:37:23 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id TAA29676 for ; Fri, 1 Sep 1995 19:37:15 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id TAA22382 for freebsd-hackers@freebsd.org; Fri, 1 Sep 1995 19:37:15 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id SAA16004 for freebsd-hackers@freebsd.org; Fri, 1 Sep 1995 18:45:04 +0200 From: J Wunsch Message-Id: <199509011645.SAA16004@uriah.heep.sax.de> Subject: Re: 16-bit pids? (was Re: 16, 32, and 64bit types?) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Fri, 1 Sep 1995 18:45:00 +0200 (MET DST) Reply-To: freebsd-hackers@freebsd.org (FreeBSD hackers) In-Reply-To: from "Brian Tao" at Sep 1, 95 09:29:59 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1584 Sender: hackers-owner@freebsd.org Precedence: bulk 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. 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. ;-)