Schwarz, Konrad wrote in
<a45b1767f1002449a37508c2cc6003d7172fb...@defthw99em4msx.ww902.siemens.net>:
|> -----Original Message-----
|> From: Robert Elz <k...@munnari.oz.au>
|> Sent: Sunday, March 15, 2020 13:47
|> To: shwaresyst <shwares...@aol.com>
|> Cc: austin-group-l@opengroup.org
|> Subject: Re: Weird possibility with async processes, $!, and long \
|> running scripts
|>
|> Date: Sun, 15 Mar 2020 11:39:27 +0000 (UTC)
|> From: shwaresyst <shwares...@aol.com>
|> Message-ID: <1641208969.3419054.1584272367...@mail.yahoo.com>
|>
|>| For that purpose both still running processes and zombie processes have
|>| to be considered as active where new ID selection would be concerned.
|>
|> Yes, the kernel makes that happen - as long as the zombie still exists, \
|> there is no problem (making that happen was the object of my
|> first two semi-solutions - neither of which is particularly nice, \
|> and leaving the process table cluttered with zombies isn't either).
|>
|> Harald's suggestion of stopping scripts using pids and requiring \
|> using job designators (%1 etc) would certainly help, as then the shell
|> knows which is being referred to - wait becomes trivial to do correctly \
|> and a built in kill can object to signalling a process (job) that has
|> already completed.
|>
|> But that would be a mammoth culture change, and only works when processe\
|> s are referenced using built-in shell commands - the job
|> designators mean nothing anywhere else.
|>
|> kre
|
|For the sake of completeness:
|A similar suggestion would be for a shell caching expired PIDs to renumber \
|these for uniqueness internally, and for kill and other built-ins taking \
|PIDs to use this renumbering. Similarly, POSIX utilities using PIDs \
|such as ps would need to be made aware of this renumbering, perhaps \
|by turning them into built-ins. Finally, applications would need \
|to be able to make use of this renumbering, i.e., by adding new entries \
|to the shell's table, so that when they report process IDs, they can \
|use the renumbering. This leads to requiring this renumbering to be \
|globally unique, since there is no requirement for these applications \
|(e.g. daemons) to be connected to the session's shell in any way.
|
|Ultimately, this turns into a system functionality, pretty much identical \
|to the existing process table.
|
|It seems much better to extend the existing interfaces to be able to \
|leave zombie processes in the core process table until they can be \
|removed without causing ambiguity. As always, correctness trumps effici\
|ency.
In the past (begin of August last year on bash-bug) i _thought_
My guess would have been that if i kill(1) a job specification,
then the sh(1)ell would refuse to use its builtin kill(1) to kill
a PID that was saved away from ${!}, and the process in question
has already terminated.
I went over a lot of trouble when implementing parallel tests for
the MUA i maintain, saw failing FIFO synchronisation reliability,
and finally had to go back to my initial design which uses
a temporary PID file for each and every started test, managed by
the test and the parent. I said
I mean, to reiterate, all i really need would be
..start tests, save $! in JOBLIST as we go..
wait --no-forget-jobs --timeout $TIMEOUT $JOBLIST
kill -KILL $JOBLIST
wait $JOBLIST
That is just plain impossible to do! Instead of this, hmm, three
liner, i need ~250 lines complicated synchronization code, lots of
interaction between a parent and a reaper process to supervise all
the started tests[1].
[1] https://git.sdaoden.eu/cgit/s-nail.git/tree/mx-test.sh#n342
It would be very nice if POSIX could so something about this for
the future. The future likely is more not less parallelism.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
