Rethinking race-free process signaling

When building my Yocto image from scratch on my 8 core 16 thread machine PIDs used to wrap around ~100 times during an hour. While I have never explicitly noticed any technical race condition the human race condition was annoying. During debugging I assume that a process with a smaller pid has started first when searching for the root cause of problem. Yocto appends the pid to the names of it log files. With the pids wrapping around so fast, they basically had zero value.

Some what resistingly I changed pid_max to 999999 some months ago. With the 15 bit limit in use for decades I expected something to break. But luckily I have not observed any breakage (although I'm ready to believe those who say they have seen broken SW). Only (command line) user friendliness has suffered a bit. Most of the pids are 6 digits to remember. But hey, that's what I wanted...

It's indeed strange that the 15 bit limit has lived for so long. On the other hand in desktop usage and probably also in many server cases the process creation rate has not increased that drastically as many other performance parameters during the last 20 years.

It can't harm if the kernel hackers fix this issue in any case.When thinking about pid namespaces and mount namespaces involved we can just hope it doesn't get too complicated to be usable in real life...