delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2004/09/16/22:48:17

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-Id: <3.0.5.32.20040916224329.0082c940@incoming.verizon.net>
X-Sender: vze1u1tg AT incoming DOT verizon DOT net
Date: Thu, 16 Sep 2004 22:43:29 -0400
To: chet AT po DOT cwru DOT edu, cygwin AT cygwin DOT com
From: "Pierre A. Humblet" <Pierre DOT Humblet AT ieee DOT org>
Subject: Re: Bash returns incorrect process status
Cc: ronald AT landheer DOT com
In-Reply-To: <040916185049.AA27432.SM@caleb.ins.cwru.edu>
References: <Message from cgf AT cygwin DOT com of Thu, 16 Sep 2004 14:43:54 -0400 (id <20040916184354 DOT GE7504 AT trixie DOT casa DOT cgf DOT cx> <41499B4A DOT 207AC15F AT ieee DOT org> <040916151300 DOT AA27319 DOT SM AT caleb DOT ins DOT cwru DOT edu> <20040916154409 DOT GC681 AT trixie DOT casa DOT cgf DOT cx> <040916172728 DOT AA27372 DOT SM AT caleb DOT ins DOT cwru DOT edu> <20040916184354 DOT GE7504 AT trixie DOT casa DOT cgf DOT cx>
Mime-Version: 1.0

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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019