>> Why is the pid value limited to 15 bits on _all_ architectures?
>> I read somewhere that libc5-i386 is restricted to signed short,
>> but what about the other architectures?
>>
>> And get_pid() doesn't contain an "out of pid" detection. AFAICS one
>> thread can block 3 pid values (pid, pgrp, session), we must limit
>> the number of threads to 10.000 on i386.
>
> Yes, sooner or later we'll have to change this, and probably soon
> is better than late. There are some security problems with the
> re-use of pids.
>
> Last January I made the following patch, and have used it since then.
> There are no problems with pids going up to many millions.
There are plenty of problems, starting with the very obvious
annoyance of having to type 10-digit numbers to kill processes.
Current limit, on a standard 80-column terminal:
$ ps j
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
22221 11111 12386 12386 tty1 12386 SW 500 0:00 foo
12386 12387 12386 12386 tty1 12386 SW 500 0:00 xload -nolabel -geometr
12387 12398 12386 12386 tty1 12386 SW 500 0:00 bar
Your proposed limit, wrapping to two lines per process:
$ ps j
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
1000022221 1000011111 1000012386 1000012386 tty1 1000012386 SW 500 0:00 foo
1000012386 1000012387 1000012386 1000012386 tty1 1000012386 SW 500 0:00 xload -nolabel -geometry 32x20+0+0 -bg grey60 -update 5
1000012387 1000012398 1000012386 1000012386 tty1 1000012386 SW 500 0:00 bar
Eeeew, gross! Going to 99999 would be tolerable. I think it makes sense
to use the low 15 bits directly as a process table index, and have the
two bits above that take on values 0, 1, and 2.
Going to high values is likely to break SCO binary support.
-
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/