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.

Also, the size of pid_t isn't dispositive. Obviously, it has to be >= the maximum pid, but the max pid might be (and usually is) less than "pid_t MAX". On the system I just tested on, pid_t is the same as int, which is 31 bits
(not counting the sign bit). Note that pid_t does have to be a signed
type, since some of the functions (e.g., kill(2)) can take negative pids.

There are trivial concerns, such as how many columns PIDs take up in the >output of ps(1).

Heh. Yeah, I've noticed that on systems with large pids (7 digits), ps listings sometimes look a little funky.

I thought random assignment of PIDs was standard by now.

I'm pretty sure that on all of my systems, it is still incremental.
(Maybe we have different understandings of what the word "random" means)

But it is a wide, wide world. Maybe things are different outside of my
little corner of it.

--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/InsaneParty

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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).

(Not that I had anytime needed more than a fraction of these;
currently "only" about 2%.)

Janis

[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-10-07 at 04:58 Janis Papanagnou wrote:

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).

32768 is just kernel's default, it can be changed using sysctl
or by writing directly to the file mentioned above.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Noam

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 07.10.2024 13:53, Kenny McCormack wrote:

[...]

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.

Yes, any [multi-user] server system will likely need larger limits
(nowadays). I forgot that my (de facto) "single-user" system is in
principle able to serve hundreds of users (or more) and must be
able to handle all their processes.

(*) And, as noted earlier, having big pid numbers makes "ps" listings weird.

IMO the 'ps' options and output is anyway a pain per se. I wonder
why I haven't yet written my own ps-fontend (based on option '-o');
probably because I don't use it often, only in case of problems.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 07.10.2024 13:53, Kenny McCormack wrote:

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.

Yes, any [multi-user] server system will likely need larger limits (nowadays). I forgot that my (de facto) "single-user" system is in
principle able to serve hundreds of users (or more) and must be
able to handle all their processes.

My computer has a baseline of about 360 PIDs, rising to about 430 after
logging in and starting a few typical applications. 15-bit PIDs could
handle a hundred of me with plenty of room to spare.

_On Linux_ process IDs and thread IDs share the same number space which
changes the picture quite a bit: 15 bits would only support a handful of
users (with my profile) since some of those typical applications create
many threads.

All this assumes desktop users (a system serving terminal-only users
might have a lot more headroom) and that no other resource runs out
first.

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 7 Oct 2024 18:29:00 +0200, Janis Papanagnou wrote:

Since processes are handled by the OS kernel what does that imply...?
A common process/thread interface in Linux?

Both fork(2) and POSIX thread creation are essentially wrappers around the underlying Linux-specific clone(2) call.

<https://manpages.debian.org/2/clone.2.en.html>

You’ll notice there are a lot more options in there besides creating pure POSIX-style processes and pure POSIX-style threads.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)