Sujet : Re: (bash) How (really!) does the "current job" get determined?
De : gazelle (at) *nospam* shell.xmission.com (Kenny McCormack)
Groupes : comp.unix.shellDate : 05. Oct 2024, 16:02:45
Autres entêtes
Organisation : The official candy of the new Millennium
Message-ID : <vdrkel$2r9tv$1@news.xmission.com>
References : 1 2 3 4
User-Agent : trn 4.0-test77 (Sep 1, 2010)
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 -