G'day... Whilst this discussion is pretty great - I would like to note that the practical purpose of knowing the size of a PID is so that I can store the current processes' PID in an MySQL database, and the process is a Perl script.
Based on the discussion so far, I'm making a pretty safe bet that a MEDIUMINT value (2^24) unsigned (0 - 16,777,215) will be more than sufficient. I don't know of a /running/ process that could have a negative value for its PID. (Any reasons why this wouldn't be sufficient?) (Having said all this, it's still quite fun and educational to watch all this great discussion.) Thanks! Regards, Michael S. E. Kraus Technical Support Specialist Wild Technology Pty Ltd [EMAIL PROTECTED] ________________________________ ABN 98 091 470 692 Level 4 Tiara, 306/9 Crystal Street, Waterloo NSW 2017, Australia http://www.wildtechnology.net The information contained in this email message and any attachments may be confidential information and may also be the subject of client legal - legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. This email and any attachments are also subject to copyright. No part of them may be reproduced, adapted or transmitted without the written permission of the copyright owner. If you have received this email in error, please immediately advise the sender by return email and delete the message from your system. -----Original Message----- From: Robert Collins [mailto:[EMAIL PROTECTED] Sent: Monday, 18 October 2004 10:53 AM To: Glen Turner Cc: Michael Kraus; [EMAIL PROTECTED] Subject: Re: [SLUG] Maximum process ID On Sat, 2004-10-16 at 14:37 +0930, Glen Turner wrote: > Robert Collins wrote: > > On Fri, 2004-10-15 at 15:33 +1000, Michael Kraus wrote: > > > >>I'm developing a database application that uses the inserting > >>processes pid. Problem is that I'm wondering how big this pid should be? > > > > > > sizeof(pid_t) IIRC. Its system specific. > > Technically, PID is also signed since > pid_t f; > f = fork(); > can return -1 on error. > > Personally I'd go with a signed 32bit integer, since that is what the > GNU C library uses for pid_t. And its really the C library's > definition, rather than the kernel's, which counts. > > Any kernel in it's right mind is going to avoid negative PIDs as that > isn't the user's expectation; I note the Amos' message saying that the > Linux kernel currently allows PID values 1 to 4,194,303. This kindof misses the point. pid_t is *hardware and software* platform specific. The libc typedef on your platform is the only one that matters - and its not the same everywhere. Going with 32bit signed int may make sense if Michaels platform uses that for pid_t, on all the machines doing inserts, consistently. But its highly likely that whatever intended use the pid field in the database has, its in appropriate. (Why is left as an exercise for the reader). Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
