On Fri, Apr 26, 2002 at 10:08:10AM -0700, Christopher Keller wrote: > > The linux kernel uses an incremental approach to generating process > ID's, or PID's as we know and love them. ..... > In order for a > duplicate or earlier PID to generated/assigned the kernel would have to > [quickly] cycle through all avaiable PID's in order to loop back around. Why "quickly"? I have seen many times PID counter to wrap around without really trying. There are only 15 bits for that number. > Seeing as how we are talking about re-assigning the PID nicety shortly > after the X server is started, the possiblity of the kernel looping > through all avaiable PID's to actually choose a lower PID is pretty > high. Could you break this? Yes, no problem. Without any sweat. > Crap shoot? Hardly. Well, as far as a good sysadmin practice is concerned there is really no more polite way to call that. You just refuted your own claims. There is no point to use broken hacks; especially when a correct way to do that is simpler even if 'pidof' is not available. > Your point about multiple X-servers is a good one, however as I > mentioned this is just a plain old desktop. On a "plain old desktop" in my home my wife and my son are using the same machine (I usually hack on something else :-). They like their desktops in a totally different way in many details. So the second person which showed up after X was restarted for whatever reasons fires up, from a text console, the second server on a display ":1" and now you can trivially switch between these desktops usually by going from a console 7 to 8 and back. This still does not include those clients which may come over a network with a display somewhere else - which happens quite regularly. This IS a multiuser operating system. Michal
