Just Curious:
When I started with Linux (when the whole kernel would still fit on a
3.5 inch floppy), there was only one series of PIDs; now there seem to
be several, running concurrently. Early in the session. PID numbers are
greater than they used to be.

Is there a reason for this?

Doug.

On Thu, 07 Jul 2022 10:18:32 -0400, Doug Laidlaw <laidlaws@hotkey.net.au> wrote:

> Just Curious:
> When I started with Linux (when the whole kernel would still fit on a
> 3.5 inch floppy), there was only one series of PIDs; now there seem to
> be several, running concurrently. Early in the session. PID numbers are
> greater than they used to be.
>
> Is there a reason for this?

1. Multi threaded programming for better utilization for multiple cores with
each thread being given it's own pid.
2. Making programs better at continuing to work even if some parts crash by
using multiple processes.

Run htop as root. Change it to sort by pid. Press K to toggle the showing of
kernel threads on (press K again to toggle it off). Each thread is assigned a
pid. In the case of the kernel on my system, the last kernel pid is 562. Not
all of the threads are still running, so there are gaps in the numbers.

Similarly use H to toggle user thread displays on or off.

Some programs use multiple processes so that one failing doesn't stop the whole
program (eg. firefox). One tab crashing doesn't kill the entire browser.

Regards, Dave Hodgins

On 7/7/22 07:18, Doug Laidlaw wrote:
> Just Curious:
> When I started with Linux (when the whole kernel would still fit on a
> 3.5 inch floppy), there was only one series of PIDs; now there seem to
> be several, running concurrently.  Early in the session. PID numbers are
> greater than they used to be.
>
> Is there a reason for this?
>
> Doug.

The kernel is full of drivers for various hardwares, new features for
the more complex functions required for day to day
computing. That the kernel is full of drivers is a problem for
me but the alternative would make Linux less able to compete. The
HURD kernel is not viable yet.

I suggest you look up Kernel News using DuckDuckGo.

bliss - brought to you by the power and ease of PCLinuxOS,
the Perfect Computer Linux Operating System(for me),
A Rolling Release, Rocking kernel 5.18.9!
and a minor case of hypergraphia.

--
bliss dash SF 4 ever at dslextreme dot com

On 07.07.2022 at 17:00, David W. Hodgins scribbled:

> On Thu, 07 Jul 2022 10:18:32 -0400, Doug Laidlaw
> <laidlaws@hotkey.net.au> wrote:
>
> > Just Curious:
> > When I started with Linux (when the whole kernel would still fit on
> > a 3.5 inch floppy), there was only one series of PIDs; now there
> > seem to be several, running concurrently. Early in the session.
> > PID numbers are greater than they used to be.
> >
> > Is there a reason for this?
>
> 1. Multi threaded programming for better utilization for multiple
> cores with each thread being given it's own pid. [...]

More precisely, GNU/Linux uses the native POSIX thread model, in which
threads appear as individual processes, each with their own PID.

Back in the days Doug is talking about, Linux threads were not
enumerated with PIDs yet, because the native POSIX thread model had not
yet been adopted into the kernel and into glibc. The default was a
different threading model with threads having the PID of the parent
process, and the switch to native POSIX threads happened gradually and
distribution-dependent, around 2004-2005.

--
With respect,
= Aragorn =

On Fri, 8 Jul 2022 00:18:32 +1000, Doug Laidlaw wrote:
> Just Curious:
> When I started with Linux (when the whole kernel would still fit on a
> 3.5 inch floppy), there was only one series of PIDs; now there seem to
> be several, running concurrently. Early in the session. PID numbers are
> greater than they used to be.
>
> Is there a reason for this?

Every program/process gets a new pid. System keeps track of last pid used,
My system goes through all pids in about 24 hours. It is up 24/7.

As you can see current pid is kinda high at the time of this reply.
# ps aux | grep -Eie kernel
root 1547313 0.0 0.0 9128 772 pts/7 S+ 17:54 0:00 grep -Eie kernel