[Top][All Lists]

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

Re: bash sometimes don't wait for children process

From: Roman Rakus
Subject: Re: bash sometimes don't wait for children process
Date: Thu, 16 Oct 2008 14:16:50 +0200
User-agent: Thunderbird (X11/20080723)

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.


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.

reply via email to

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