Path: ...!weretis.net!feeder9.news.weretis.net!xmission!nnrp.xmission!.POSTED.shell.xmission.com!not-for-mail
From: gazelle@shell.xmission.com (Kenny McCormack)
Newsgroups: comp.unix.shell
Subject: Re: (bash) How (really!) does the "current job" get determined?
Date: Sat, 5 Oct 2024 15:02:45 -0000 (UTC)
Organization: The official candy of the new Millennium
Message-ID: <vdrkel$2r9tv$1@news.xmission.com>
References: <vdn864$2p69n$1@news.xmission.com> <slrnvg0alc.1le3.naddy@lorvorc.mips.inka.de> <vdpgf0$bchi$1@dont-email.me> <slrnvg0s5f.1qk1.naddy@lorvorc.mips.inka.de>
Injection-Date: Sat, 5 Oct 2024 15:02:45 -0000 (UTC)
Injection-Info: news.xmission.com; posting-host="shell.xmission.com:166.70.8.4";
	logging-data="2992063"; mail-complaints-to="abuse@xmission.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: gazelle@shell.xmission.com (Kenny McCormack)
Bytes: 3259
Lines: 50

In article <slrnvg0s5f.1qk1.naddy@lorvorc.mips.inka.de>,
Christian Weisgerber  <naddy@mips.inka.de> wrote:
....
>Job control does not require an interactive shell or a terminal
>session.  It can be used in scripting.  That's the facts.

True.  But as they say, there are none so blind as those that will not see.

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

The problem of re-used pids is something people frequently worry about, but
which is (for all practical purposes) never seen in real life.  For one
thing, even in the old days of 15 bit pids, it is still basically
impossible for it to cycle all the way through in any sort of reasonable
time frame.  Nowadays, we have 22 bit pids, so it is even less likely (*).

Some other notes about this:
    1) As far as I know, all "normal" Unixes use the simple cycle method of
    allocating pids - i.e., just keep going up by 1 until you reach the max,
    then start over again at 1 (or 2).  But I think at one point, it was
    thought that having "predictable" pids was somehow bad for "security",
    so they had a random assignment method.
    2) Other non-Unix, but Unix-like, environments, such as Windows, treats
    pids differently.  I think Windows aggressively re-uses them, so one
    probably needs to be more careful there than in regular Unix/Linux.
    3) As I said, this is more of a problem in theory than in practice, but
    the pidfd*() functions were inspired by a perceived need for being able
    to be sure.

(*) Actually this kinda begs the question, though, why 22 bits?  Why not all 32?
Or 64?  Incidentally, there are comments in the kernel to the effect of "22
bits has to be enough; 4 million pids should be enough for anyone" (just
like 640K, I suppose...)

-- 
Kenny, I'll ask you to stop using quotes of mine as taglines.

    - Rick C Hodgin -