Date: Tue, 29 Aug 1995 07:24:08 +1000 From: Bruce Evans <bde@zeta.org.au> To: frank@exit.com, hackers@freefall.FreeBSD.org Subject: Re: 16-bit pids? (was Re: 16, 32, and 64bit types?) Message-ID: <199508282124.HAA14752@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Sixteen bits for PID_MAX? Yukko! IMHO, this should be at least 32, and >preferably a black-box type (handled by allocate_pid(), not by an int >increment, as fast that that might be -- it's still one of the least >critical bits of fork()). Some distributed systems need at least 32 >bits for the pid, since they add node information, and a black-box type >would make this much easier. >Granted, it's a nontrivial change, but it would be nice to see some system >do it right. I don't think there's any inherent reason why pid_t should >be limited to an int (of any size) in modern Un*ces. pid_t shall be a signed arithmetic type in POSIX systems (POSIX.1 section 2.5). The meaning of the bits isn't specified so you can treat it as a cookie except for the sign bit (which is presumably only required to encode process groups in kill() etc.). Does anyone know why POSIX specifies `signed arithmetic' types? The C standard specifies that the `arithmetic types' are the signed and unsigned integral types and the floating point types, so the `signed' in `signed arithmetic' doesn't add anything, but it suggests that POSIX really meant to say `integral' instead of `arithmetic'. Has anyone written a big portable program that supports dev_t, gid_t, ino_t, mode_t, nlink_t, off_t, pid_t, ssize_t and uid_t being arbitrary arithmetic types including long double? Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508282124.HAA14752>