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

[Mike Touloumtzis <miket@geoworks.com>]

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/