> You are making it harder than it is.
>
> There have been two major possibilities discussed as far as a 32-bit pid:
>
> 1 The 32-bit pid is constructed of a 16-bit pid and a 16-bit "other"
> that might include tid or some clustering information.
1) This isn't very clean, we can see how expandable the merging of major
and minor devices #s is...
2) Some people really want a 32-bit process ID. I've heard of rare
accounts of people running out, and with software like apache that isn't
threaded yet...
> The first possibility is easily dealt with; old binaries don't use threads
> anyway, and aren't clustered apps, so their getpid() would return the low
> 16 bits, which is sufficient for these single-threaded apps.
Which leaves the limit of 32K single threaded processes...
> The second possibility is decided a couple lines of kernel code at
> most, and as no portable software will rely on a true 32-bit pid
> space, it would be reasonable to make it a run-time option at what
> value pids are wrapped.
I don't see how this is really different from the current 16-bit IDs...
unless there are special functions to return the real 32-bit ID...
> People who value binary compatibility would leave the default of
> 32k, and those who want a large pid space change it to any value
> that fits in 32 bits with sysctl or /proc/sys/.
What happens when/if you shrink the PID space on the fly and there are
processes in the upper range? Ugg...
> Having separate pid spaces doesn't really work well; I can come up
> with far more problems than exec.
True...
-Rob H.