I wasn't suggesting it, I was merely mentioning that it was one of
the proposals that has been made. I wanted to point out that my
proposal handles all the suggested cases, and I had no intention of
judging a beauty contest while doing so.
>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...
Uh, if you have over 32k processes running at the same time, you are
going to have other problems... Legacy machines running legacy code
are not going to have this problem. Consider that the size of the
process table is currently 512 processes by default (IIRC).
But, sure, if someone builds a kernel with over 32k maximum processes,
it changes the default starting wrap number and they can't run
legacy apps that assume 16-bit pids. I'm trying to come up with
a way to create kernels that can support both legacy and new apps
by default, but with which support for legacy code can be traded off
for new features BY THOSE WHO DESIRE THE NEW FEATURES.
>> 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...
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.
>> 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...
Of course, it is obvious that you are not allowed to shrink it below
what already exists. It would default to 32k and perhaps you would
only be allowed to increase it. Even if you were alowed to shrink it
and only prevented from shrinking it lower than any existing pid value,
it wouldn't be a problem.
But, as I think about it, it wouldn't hurt the kernel even to ignore
that rule and let you shrink the pid space whenever you wanted to --
the next process created would be low-numbered and some processes
would be invisible to legacy apps. So? It as least allows the legacy
apps to run!
My point is that it is possible to maintain compatibility with old apps
without horribly ugly breakage and without crippling new applications.
Of course there are direct conflicts in some areas; that's the whole
point of my proposal -- to mitigate the effects of the conflicts. I'm
trying to make it possible to maintain legacy apps, yet not stifle
growth and development of new features.
Consider that the alternative is to enable the new features and break
all the legacy apps. Some of us, at least, care whether software
compiled two years ago starts breaking.
michaelkjohnson
"Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?"