Messages in this thread | | | Date | Mon, 14 Jun 1999 17:43:00 -0700 | From | Mike Touloumtzis <> | Subject | Re: size of pid_t (was: Re: NR_TASKS as config option) |
| |
Some Unices (AIX?) use random PID allocation to make PID prediction more difficult. Is this perceived to be worth it, or is it a non-issue?
miket
On Sun, Jun 13, 1999 at 09:48:10PM +0200, Pavel Machek wrote: > > > > > Yes, eventually we'll have to. > > But a 32-bit pid_t is not so bad: > > With a hundred new processes spawned every second > > a 32-bit pid_t will wrap only after about 500 days. > > Everyone should assume PID's are being reused! If you have buggy apps > which assume pid's not to be reused, then just watch your proc and > reboot when you are coming to 2G-th process ;-). (Ok, there's one bug > in kernel w.r.t. pid wrapparound - in console and it allows console > user to send arbitrary signals to newly created processes.) > > What is bad is that clusters pretty much need 32bit pids... > > > Conclusion: > > - a 64-bit pid_t is most convenient for the kernel, but > > gives trouble with libc. > > - a 32-bit pid_t is what we have today, but we use only > > 15 bits because of SYSV IPC (or perhaps other reasons > > I am unaware of). > > And becuase /proc internals. But please please go and change it. > > Pavel
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |