On Tue, Jul 15, 2025 at 11:39 AM Chet Ramey <chet.ra...@case.edu> wrote: > > On 7/15/25 11:35 AM, Zachary Santer wrote: > > On Tue, Jul 15, 2025 at 10:29 AM Chet Ramey <chet.ra...@case.edu> wrote: > >> > >> With respect to not consulting the list of saved pids if given a list > >> of pid arguments, solving this problem. > > > > I'd like to think that's just a stopgap, but yeah, I can play around with > > that. > > Why do you think it would be a stopgap?
We had that super-long discussion, and then you just throw away a pretty big part of those changes immediately after there's any kind of issue? Maybe I was being optimistic. It doesn't seem to me like consulting the list of saved pids or not would even be particularly relevant to the issue here. 'wait -n' is mistakenly returning the termination status of a procsub, which wouldn't show up in that list to begin with, if I remember correctly. This instead of waiting for and returning the termination status of the single regular background process whose pid was given to it explicitly, even though 'wait -n' was called before that background process had terminated, and thus it also wouldn't show up in that list. If we *are* looking at a race condition thing, your change could have affected timing. Not sure if I can realistically dive into and understand the source code myself right away.
