Re: size of pid_t (was: Re: NR_TASKS as config option)

Mike Touloumtzis (miket@geoworks.com)
Mon, 14 Jun 1999 17:43:00 -0700


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/