Sujet : Re: pid ranges (Was: (bash) How (really!) does the "current job" get determined?)
De : gazelle (at) *nospam* shell.xmission.com (Kenny McCormack)
Groupes : comp.unix.shellDate : 07. Oct 2024, 12:53:42
Autres entêtes
Organisation : The official candy of the new Millennium
Message-ID : <ve0i46$2tnuv$2@news.xmission.com>
References : 1 2 3 4
User-Agent : trn 4.0-test77 (Sep 1, 2010)
In article <
vdviph$1io9a$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+
ng@hotmail.com> wrote:
On 05.10.2024 19:13, Kenny McCormack wrote:
In article <slrnvg2nc2.2dut.naddy@lorvorc.mips.inka.de>,
Christian Weisgerber <naddy@mips.inka.de> wrote:
...
time frame. Nowadays, we have 22 bit pids, so it is even less likely (*).
>
"We" do? Offhand, I don't know the size of pid_t, much less how
much of its numerical range is actually used.
On Linux, check out: /proc/sys/kernel/pid_max
As I read the various posts on the subject, 15 bit is still the limit on 32
bit systems, 22 bit on 64 bit systems. But, of course, YMMV.
>
Hmm.. - my [a bit rusty] 64 bit Linux displays 32768 (15 bit).
As another poster has already noted, 15 bits is still the default, but the
limits are as shown above. Presumably, this can be set in some startup
file (which seems to be the case on the machine I am typing on now).
Personally, I don't really see the point (in increasing the max pid #).
For practical purposes, it seems unlikely you'll ever need it (*), but then
again, maybe there really are big systems out there that need to be running
more than 32K processes at a time.
(*) And, as noted earlier, having big pid numbers makes "ps" listings weird.
-- The randomly chosen signature file that would have appeared here is more than 4lines long. As such, it violates one or more Usenet RFCs. In order to remainin compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/Noam