Date: Mon, 28 Aug 1995 16:31:17 -0500 (CDT) From: Mike Pritchard <mpp@mpp.minn.net> To: frank@exit.com (Frank Mayhar) Cc: hackers@freefall.FreeBSD.org Subject: Re: 16-bit pids? (was Re: 16, 32, and 64bit types?) Message-ID: <199508282131.QAA27212@mpp.minn.net> In-Reply-To: <199508282036.NAA04576@exit.com> from "Frank Mayhar" at Aug 28, 95 01:36:26 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Frank Mayhar wrote: > > Just an aside, not directly related to the original subject. > > > Type FreeBSD NetBSDr1994/12) Right > > ---- ------- --------------- ----- > > min_pid_t - - u16_t (for PID_MAX = 30000) > > kernel_pid_t - - kernel_promote(min_pid_t) > > pid_t long int32_t user_promote(min_pid_t) > > 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. Since the subject of PID_MAX has come up, what is the reason for having it set to 30,000? That isn't really that large of a value, especially on a busy system. How about raising it to something like 90,000? -- Mike Pritchard mpp@mpp.minn.net "Go that way. Really fast. If something gets in your way, turn"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508282131.QAA27212>