On Sat, 08 Oct 2005 11:02:08 +0200, Roberto Nibali said:
A simple stupid test would wrap the pids at 32k:
Right. The fun starts when you do 'echo NNN > /proc/sys/kernel/pid_max' for some NNN > 32k. On 32bit boxes 64K is the limit due to the /proc inode wonkiness, but on 64bit kernels it's just a matter of how much RAM you have. ;)
I knew that you could have 4Mio threads but I somehow wasn't aware that you can have 4Mio forked processes. Since the Linux world changed to NPTL we do not necessarily call clone() anymore when doing a pthread_create() and thus we don't really fork() anymore, as with linux_threads-0.10.
The numbers returned by getpid() and gettid() come out of the same PID space, and the vast majority of programs aren't thread-aware, and get their PID via fork() or vfork() anyhow...
# cut -f2 -d'[' /var/adm/seclog | cut -f1 -d']' | sort -nr | uniq | head 191446 191208 191188 191186 191184 191170 191124 191122 191108 191104
Mhh, these must be PIDs I reckon, since IIRC AIX can only handle 512 threads per process, right?
Yep. Those are indeed process IDs, coming out of binaries that I *know* aren't multi-threaded...
Thank you, Valdis, of course. Since I haven't actively remarked high PIDs in my current development field I was still under the distinct impression that PIDs are 16bit; I probably just overlooked the number of digits in the logfiles all those years.
It's effectively an 'int' - any code that assumes a smaller range will fail in the most interesting ways in the near future... :)