pid ranges (Was: (bash) How (really!) does the "current job" get determined?)

In article <slrnvg2nc2.2dut.naddy@lorvorc.mips.inka.de>,
Christian Weisgerber  <naddy@mips.inka.de> wrote:
...

time frame.  Nowadays, we have 22 bit pids, so it is even less likely (*).

>
"We" do?  Offhand, I don't know the size of pid_t, much less how
much of its numerical range is actually used.

On Linux, check out: /proc/sys/kernel/pid_max

As I read the various posts on the subject, 15 bit is still the limit on 32
bit systems, 22 bit on 64 bit systems.  But, of course, YMMV.

Also, the size of pid_t isn't dispositive.  Obviously, it has to be >= the
maximum pid, but the max pid might be (and usually is) less than "pid_t MAX".
On the system I just tested on, pid_t is the same as int, which is 31 bits
(not counting the sign bit).  Note that pid_t does have to be a signed
type, since some of the functions (e.g., kill(2)) can take negative pids.

There are trivial concerns, such as how many columns PIDs take up in the
output of ps(1).

Heh.  Yeah, I've noticed that on systems with large pids (7 digits), ps
listings sometimes look a little funky.

I thought random assignment of PIDs was standard by now.

I'm pretty sure that on all of my systems, it is still incremental.
(Maybe we have different understandings of what the word "random" means)

But it is a wide, wide world.  Maybe things are different outside of my
little corner of it.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/InsaneParty