Re: bash sometimes don't wait for children process

[Chet Ramey]

>             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)?

To see if we created a process in execute_simple_command that we need
to wait for.  The presence of non-Unix systems that tend to recycle
pids quickly (or allocate at random from a small pool) makes the check
unreliable, so we call wait_for every time. 

> 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.

If you're saying that the kernel will keep giving out pid 32769 over and
over again as long as it's available when the next call to fork() comes in,
then that's reason enough to define RECYCLES_PIDS.  Bash assumes Unix
systems have a pid cycle of at least 16 bits and that pids increase until
wraparound.  Non-Unix systems like cygwin behave differently and prompted
the inclusion of the RECYCLES_PIDS code.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU    chet@case.edu    http://tiswww.tis.case.edu/~chet/