Re: Glibc, large PIDs etc (Was: Killing clones) (fwd)

Jim Nance (jlnance@avanticorp.com)
Tue, 26 Aug 1997 08:36:33 -0400 (EDT)


Forwarded message:
>
> It is not "really different" behavior by default -- by default it is
> precisely the same as it has always been, except that there are 16-bit
> and 32-bit interfaces. However, it enables "really different" new,
> useful behavior for those who want it AND are willing to trade off
> the ability to run legacy apps.

I think this discussion originally came up because we were thinking of
using the high bits of the PID for threads. From my casual observations
of the thread discussion going on in this list, it now looks like threads
will NOT be implemented this way. If this is true, do we really need
32 bit PIDs? My Digital Unix system seems to still use 16 bit values,
and it looks like Solaris does too. As far as I can tell, the only
limitation this imposes is limiting the maximum number of running processes
to 32K.

Since glibc can deal with a 32 bit PID and no one is bumping into a 32K
process limit yet perhaps we should just wait for a while before changing
the kernel. If we do that than perhaps by the time we really need to
switch to 32 bit PIDs (hopefully 5 to 10 years) everything will be glibc
based and just work.

Thanks,

Jim