[ This is getting off-topic, sorry. ]

On 07.10.2024 15:31, Richard Kettlewell wrote:
>
> _On Linux_ process IDs and thread IDs share the same number space which
> changes the picture quite a bit: [...]

This is interesting.
Since processes are handled by the OS kernel what does that imply...?
A common process/thread interface in Linux?
Is that defined by POSIX threads, or is it something specific?

Is there any good link to read more about that?

(My thread times have long passed; I used it from C++, and there were
a lot of things to consider when programming with threads back then.)

Janis

In article <ve128d$1pf02$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>[ This is getting off-topic, sorry. ]
>
>On 07.10.2024 15:31, Richard Kettlewell wrote:
>>
>> _On Linux_ process IDs and thread IDs share the same number space which
>> changes the picture quite a bit: [...]
>
>This is interesting.
>Since processes are handled by the OS kernel what does that imply...?
>A common process/thread interface in Linux?
>Is that defined by POSIX threads, or is it something specific?
>
>Is there any good link to read more about that?

"man clone" is a good starting place.

In Linux, threads are almost the same thing as processes. Obviously, there
are differences, but basically, that is true. Both are created via clone(2).
(fork() is implemented on top of clone()).

--
> No, I haven't, that's why I'm asking questions. If you won't help me,
> why don't you just go find your lost manhood elsewhere.

CLC in a nutshell.

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

> [ This is getting off-topic, sorry. ]
>
> On 07.10.2024 15:31, Richard Kettlewell wrote:
>>
>> _On Linux_ process IDs and thread IDs share the same number space which
>> changes the picture quite a bit: [...]
>
> This is interesting.
> Since processes are handled by the OS kernel what does that imply...?
> A common process/thread interface in Linux?

Exactly.
In the early 2000's, the Linux kernel moved to supporting 1:1 threads,
and provided the NPTL ("Native Posix Threading Library") to provide the
POSIX application-level API to this new kernel capability.

> Is that defined by POSIX threads, or is it something specific?

It is how Linux implements the kernel-level responsibilities of POSIX
threads.

> Is there any good link to read more about that?

Plenty. Google "NPTL and Linux"

> (My thread times have long passed; I used it from C++, and there were
> a lot of things to consider when programming with threads back then.)
>
> Janis

--
Lew Pitcher
"In Skills We Trust"

Christian Weisgerber <naddy@mips.inka.de>:

> That said, here's something I stumbled across recently:
>
>
> background job &
> ...
> kill %1 # clean up
>
> What happens if the background job has already terminated on its
> own accord before we reach the kill(1)? Not much, because with job
> control, the shell knows that no such job exists. If you do this
> with "kill $!", you signal that PID, which no longer refers to the
> intended process and may in fact have been reused for a different
> process.
>

In order for the pid "$!" to have been reused for a different
process the shell would have needed call "wait()" (or
"waitpid()") beforehand.  (Otherwise the terminated process would
remain a zombie (i.e. an unwaited) process.)  Does the shell even
call "wait()" or "waitpid()" if given the "set" option "+b"?

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.

On 04/10/2024 23:48, Christian Weisgerber wrote:
>
> I'm curious myself. That said, here's something I stumbled across
> recently:
>
> background job &
> ...
> kill %1 # clean up
>
> What happens if the background job has already terminated on its
> own accord before we reach the kill(1)? Not much, because with job
> control, the shell knows that no such job exists. If you do this
> with "kill $!", you signal that PID, which no longer refers to the
> intended process and may in fact have been reused for a different
> process.
>

There would have to be a very long time in your '...' part for a pid to
get reused. I guess you could ps | grep and check the command name is
what you expect.

You can 'kill -0 <pid>' (or %<job>) for 'could I signal <pid>', rather
that actually sending a signal - it returns non-zero if it can't.

If the job finishes before you wait then the process is gone, ie not
zombied, so ksh/bash must keep track of the wait status. The job is also
gone, so only wait <pid> will get you the correct exit status.

On 2024-10-04, Christian Weisgerber <naddy@mips.inka.de> wrote:
> What happens if the background job has already terminated on its
> own accord before we reach the kill(1)? Not much, because with job
> control, the shell knows that no such job exists.

In Unix, when a child process terminates, it does not go away. The parent
process has to call one of the wait functions like waitpid in order to "reap"
that process. It can be notified of children in this state asynchronously via
the SIGCHLD signal.

The problem of PIDs suddenly disappearing and being recycled behind the parent
process' back does not exist in the operating system.

We can imagine a shell which does nothing when a child coprocess launched with
& terminates spontaneously, so that the script /must/ use the wait command.

In that shell, the process ID of that child will remain reliably available
until that wait.

Only if the shell reaps terminated coprocesses behind the script's back, so to
speak, do you have the reuse problem.

What does POSIX say? Something between those two alternatives:

When an element of an asynchronous list (the portion of the list ended
by an <ampersand>, such as command1, above) is started by the shell, the
process ID of the last command in the asynchronous list element shall
become known in the current shell execution environment; see Shell
Execution Environment. This process ID shall remain known until:

The command terminates and the application waits for the process ID.

Another asynchronous list is invoked before "$!" (corresponding to
the previous asynchronous list) is expanded in the current execution
environment.

The implementation need not retain more than the {CHILD_MAX} most
recent entries in its list of known process IDs in the current shell
execution environment.

It's seems as if what POSIX is saying is that scripts which fire off
asynchronous jobs one after another receive automatic clean up.
A script which does not refer to the $! variable from one ampersand
job, before firing off more ampersand jobs, will not clog the system
with uncollected zombie processes. But a script which does reference $!
after launching an ampersand job (before launching another one) will not
have that process cleaned up behind its back: it takes on the responsibility
for doing the wait which recycles the PID.

Anyway, that's what I'd like to believe that the quoted passage means.

> If you do this
> with "kill $!", you signal that PID, which no longer refers to the
> intended process and may in fact have been reused for a different
> process.

At the system call level, that's not what kill means. It means to
pass a certain signal (fatal or not, catchable or not) to the process.
Even if the signal is uncatchable and fatal, kill deos not mean
"make the target process disappear, so that its PID may be reused".

The waitpid system call will do that (in the situation when the process
is a zombie, and so subsequently the returned status indicates that
it exited, and with what exit code or on what signal).

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-10-05, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
> On 2024-10-04, Christian Weisgerber <naddy@mips.inka.de> wrote:
>> On 2024-10-04, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>
>>>>> What? Scripting should not go anywhere near POSIX job control, which is
>>>>> an interactive feature that requires a terminal session.
>>>>
>>>> Well, there _is_ set -m.
>>>
>>> And how will that devaluate what Kaz has said? Please elaborate.
>>
>> Job control does not require an interactive shell or a terminal
>> session.
>>
>> It can be used in scripting. That's the facts.
>
> An example of what you mean would help.

*crickets*

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca