On Dec 26, 2007 10:51 PM, Marc Aurele La France <[EMAIL PROTECTED]> wrote: > Hi. > > The -p1 patch below causes `xargs` to reap its zombied children before > attempting to fork() another child process. This is intended to make it > more difficult for a user to fill up the process table, potentially > causing other system services to fail.
First thanks for reporting the bug. I have recorded it at http://savannah.gnu.org/bugs/index.php?21960 I opted for a fix that is somewhat different to your proposal. I wanted to have xargs reap children a little more frequently than provided for in your code change (for example, before fork when -P50 is in effect). Also though, xargs had a number of variables which were signed but not indended to hold a negative quantity; some of these related to counting the number of outstanding child processes. I took the opportunity to fix that too. The change I prepared was emailed (as usual) to [EMAIL PROTECTED] and is attached to the bug at the above URL. I'll apply it to the CVS tree in a couple of days, once people have had an opportunity to review it. This means that despite your work to fix this problem, the code change you suggested wasn't the one I used. I hope you don't mind. Nevertheless your change was a good one and should you want to further contribute to findutils, we'd be glad of the help. > This is keyed on whether or not <sys/wait.h> #define's WNOHANG, but you > might want to key off of the existence of waitpid(), using the automangle > suite. I am submitting this in its current form given that waitpid() is > just about as old as wait(), older than wait3() and wait4() even, and that > there is no point in WNOHANG without waitpid() or vice-versa. I agree that waitpid is well-established. Every bit of autoconfiscation imposes a small extra maintenance burden. Partly for that reason, I decided to just assume the existence of both waitpid() and WNOHANG. Thanks again for your help. James.
