On 2/9/06, Eric W. Biederman <[email protected]> wrote:
> Jan Engelhardt <[email protected]> writes:
>
> >>> On Linux, type pid_t is defined as an int if you look
> >>> through all the intermediate definitions such as S32_T,
> >>> etc. However, it wraps at 32767, the next value being 300.
> >
> > There is also an aesthetical reason. If pids were allowed to exceed, say,
> > ten million, you would need a quite wide field in `ps` for the process
> > number which is on "normal desktop user" systems just require 5 or 6
> > decimal places. Well, what I mean, just look at this sample ps output:
> >
> > 17:59 shanghai:../fs/proc # ps
> > PID TTY TIME CMD
> > 1 - 00:00:00 init [3]
> > 4215914607 tty2 00:00:00 bash
> > 4215914653 tty2 00:00:00 ps
> >
> > mingw/msys and cygwin already have this "cosmetic problem" since windows
> > "pids" are usually above one million.
>
> Yes. Although this I'm not I'm not certain how bad the cosmetic problem
> is. Certainly significant enough that we don't want to change a good
> thing when we got it. But if there were real problems a big pid
> would solve I don't expect large pid numbers to stop us.
>
I can think of at least 3 ways to at least hide that cosmetic problem
a bit. Won't solve the problem but will make it less likely that most
people will ever encounter it.
(assuming below that we want something like 64bit pids but want to
keep pids at 5 digits as much as possible)
1. When allocating a pid for a new process, always assign the lowest
available free pid.
2. Allocate pid's as we currently do, but once we hit 99999 wrap the
pids and start allocating from free pids starting from 2 and up. only
if no pids below 99999 are free do we continue upwards and allocate
pid 100000.
3. Whenever a process terminates put its pid on a pid_reuse list. When
a new pid needs to be allocated always pick a pid from the pid_reuse
list if any are available, otherwise allocate pids as we currently do.
Any of those 3 scheemes should keep pids below 6 digits as much as
possible. We can still hit the cosmetic problem on boxes where more
than 99999 processes are actually running at the same time, but most
users will never encounter that.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]