On Fri, Aug 09, 2024 at 13:59:58 -0400, Zachary Santer wrote: > I don't necessarily understand why someone would call 'wait -n' from > the interactive shell, so I don't really know what the desired > behavior would be when they do so. Would be nice if other people want > to chime in on that point.
The only use case I'm aware of for "wait -n" was implementing a thing that runs N processes at a time, launching one new process every time an existing one completes. I could easily see someone writing a function for this and putting it in their .bashrc and using it from an interactive shell, though I haven't done this myself. The problem is that our entire understanding of what "wait -n" DOES has been annihilated. We thought it would "trigger" exactly once for every completed background process, regardless of whether they completed before or after calling "wait -n", which would allow the writing of an N-jobs-at-a-time thing. It turns out this is incorrect. Now that we know "wait -n" is a gigantic race condition with no predictability, it's hard for me to come up with any legitimate use for it. The best N-jobs-at-a-time implementation now is probably GNU xargs -0 -P, but it's a VERY distant second place behind the mythical wait -n loop.
