Re: bash sometimes don't wait for children process

[Roman Rakus]

Chet Ramey wrote:
> >             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. 
>
>   
Yes, but don't we see it if already_making_children is set to 1?
> > 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
>
>   

Yes, kernel will give you that pid, if pid numbers  are out of 32768 (or 
number set in /proc/sys/kernel/pidmax).
I think, if we define RECYCLE_PIDS we will solve this problem and don't 
introduce any other.