bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bash sometimes don't wait for children process


From: Roman Rakus
Subject: bash sometimes don't wait for children process
Date: Wed, 15 Oct 2008 15:26:06 +0200
User-agent: Thunderbird 2.0.0.16 (X11/20080723)

There is code in "execute_cmd.c" function "execute_command_internal":
...
#if defined (RECYCLES_PIDS)
       last_made_pid = NO_PID;
#endif
       last_pid = last_made_pid;
...
       if (already_making_children && pipe_out == NO_PIPE &&
           last_made_pid != last_pid)
         {
...
             exec_result = wait_for (last_made_pid);
         }

I'm wondering why we are doing assignment (last_pid = last_made_pid;) and then test it (&& last_made_pid != last_pid)? I understand we create new child process and change last_made_pid. So, for example, we have last_pid 255, same as last_made_pid. Now we create child process and change last_made_pid to that new (256 probably). Now we test if they are same, they aren't and we wait for child. But what about situating where we have a lot of process'? 32768... last_pid will be 32768, make new child with pid 32769, we go through if, wait for child. Now we do next command, last_pid will change to 32769, create child, but this child will have pid 32769 and we don't go through if and don't wait to child. It's done by kernel, but why is bash doing this check? Is it necessary? Isn't enough to check like this: if (already_making_children && pipe_out == NO_PIPE)? Or get a rid of #if defined (RECYCLES_PIDS) and do last_made_pid = NO_PID; every time? For me is better solution the lighter checking.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]