On Fri, 07 Oct 2005 23:59:27 +0200, Roberto Nibali said:
Maybe I needed sleep more than you did ;). But maybe one improvement could be you honoring the fact that PIDs are 16bit. So parsing 5 chars should be enough as an early continue out of the loop.
Erm. No. On a Linux 2.6 kernel, in include/linux/threads.h: /* * This controls the default maximum pid allocated to a process */ #define PID_MAX_DEFAULT (CONFIG_BASE_SMALL ? 0x1000 : 0x8000) /* * A maximum of 4 million PIDs should be enough for a while: */ #define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 : (sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT)) On 32-bit kernels, there's some code in the /proc that borks up if the PID is over 64K (it invents an inode number based on the pid, and the left-shift overflows). Running on a 64 bit system, the default is 4M, and can be raised *much* higher if needed. And it isn't just Linux either - seen on an AIX box: # cut -f2 -d'[' /var/adm/seclog | cut -f1 -d']' | sort -nr | uniq | head 191446 191208 191188 191186 191184 191170 191124 191122 191108 191104 Yep, PIDs pushing the 200K mark (AIX plays some funky games when generating the 'next PID' to reduce cache-line aliasing issues when dereferencing entries in some structures indexed by PID).