Date: Tue, 29 Dec 2020 10:23:07 -0500 From: Chet Ramey <chet.ra...@case.edu> Message-ID: <a750789b-e929-c8cc-db29-342eddbfb...@case.edu>
| Bash will save some number of exit statuses corresponding to terminated | asynchronous child processes, and those statuses are retrievable using | `wait'. That number varies -- POSIX says you need to save at least | CHILD_MAX statuses, but bash will look at its nproc resource limit (using | sysconf(3)) and try to save that many, up to a max of 32K in bash-5.1. This | will be sufficient in most cases. The interesting case (for shell authors, in practice this rarely, if ever, actually happens) is how to handle the case where the shell has collected (waited for) the status from a child process, but the script has yet to fetch it (that status is one of those being saved). Then, during that interval it is possible for the same pid to be assigned by the kernel for some other process - and that other process might be a child of the same shell. If that child is a fg process (never moved to bg) there's no real problem, but if it is a bg process, and its pid is exported via $! then there can be a real problem, as the script no longer has any safe documented and simple way to distinguish the two processes (they will have different %n job numbers, but scripts don't usually even consider such things). I have considered have the shell (the one I maintain, not bash) check (both parent and child) after a fork, and abort the child immediately, and simply try the fork again, if the system assigns a pid which would cause a problem like that - but never bothered to actually write the code (both parent and child after the fork can run the same test, in parallel, so there's no issue knowing what happened or what to do next .. the vfork case is similarly easy). It has never been a high priority as, in practice, the issue just doesn't arise. kre