Sujet : Re: (bash) How (really!) does the "current job" get determined?
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.unix.shellDate : 05. Oct 2024, 07:10:00
Autres entêtes
Organisation : None to speak of
Message-ID : <87bjzzqdvr.fsf@nosuchdomain.example.com>
References : 1 2 3 4 5 6 7
User-Agent : Gnus/5.13 (Gnus v5.13)
Christian Weisgerber <
naddy@mips.inka.de> writes:
[...]
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.
That's possible, but in my experience the system avoids reusing PIDs
of dead jobs for as long as possible. On typical Linux systems, the
max PID is about 2**22, and newly allocated PIDs cycle through that
range. (If you're using all the PIDs in that range simultaneously,
you've got bigger problems than running out of PIDs.)
I once ran a test to see how quickly I could make the system reuse
a PID, by forking and terminating as many processes as I could as
quickly as I could. I don't remember the details, but I think it
took the better part of an hour.
On the other hand, I think a contrived pattern of process creation
and termination could result in a PID being reused quickly. I might
try the experiment again.
-- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.comvoid Void(void) { Void(); } /* The recursive call of the void */