This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bash returns incorrect process status


At 02:50 PM 9/16/2004 -0400, Chet Ramey wrote:

>> >> >POSIX shells are required to remember at least CHILD_MAX (but
>> >> >optionally more) process statuses.  There is a gray area about whether
>> >> >or not the user can query the status of those processes, implying that
>> >> >once the status of a background or foreground job has been reported,
>> >> >its status, and the status of its constituent processes, can be
>> >> >discarded, but those rules are hard to decipher.
>> >> 
>> >> Are you saying that waitpid should be able to return the status of an
>> >> exited process when it is called repeatedly?  I've never seen anything
>> >> like that.  I thought that once you'd done a wait the process was
>> >> unzombified, it goes away, and it is unavailable for future querying.
>> >
>> >No.  The portion of the POSIX spec describing the shell's behavior is
>> >independent of the exact function used to query a process's status.  It
>> >says the shell has to remember.  It doesn't mention waitpid(), nor does
>> >it need to.
>> >
>> >You're assuming that the shell just does a waitpid() whenever it needs to
>> >get a particular process's status.  No shell does it that way.
>> 
>> My point was that unless you assume (which you can't) that you can
>> repeatedly query the OS for the status of a process, keeping an array,
>> or a linked list, or a database or whatever of pids around will cause
>> problems unless you're also storing a time component as well.  Once
>> you've queried the pid status using wait* then the pid is free to be
>> reused so remembering the process status of a pid for a long time seems
>> problematic.
>
>That's why there's the implicit requirement that the period be at least
>CHILD_MAX.  If a single process can have CHILD_MAX simultaneously
>executing children, the number of unique PIDs the system must support is
>at least CHILD_MAX+1, and there's the presumption that the PID distribution
>is uniform.
>
>Chet

But bash seems to keep at least CHILD_MAX jobs, each one of them possibly
with many (unbounded) processes. It is very easy to produce situations
where bash keeps track of thousands of pids. Many of those pids (e.g. the
first ones in pipelines) will have been waited on, and nothing prevents the
OS from reusing them. Pid aliasing can easily occur even if the OS never
reuses a pid in CHILD_MAX consecutive forks from a process.

Pierre

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]