Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Content-Type: text/plain;
  charset="iso-8859-1"
From: Ryan Bloom <rbb@covalent.net>
Reply-To: rbb@covalent.net
Organization: Covalent Technologies
To: Jeff Trawick <trawick@attglobal.net>, dev@apr.apache.org
Subject: Re: [Fwd: Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c]
Date: Fri, 19 Oct 2001 08:47:08 -0700
References: <3BD02F77.D5304945@remulak.net>
 <m3ofn3y9gn.fsf@rdu88-250-106.nc.rr.com>
In-Reply-To: <m3ofn3y9gn.fsf@rdu88-250-106.nc.rr.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20011019154709.9A18E46DFC@koj.rkbloom.net>

On Friday 19 October 2001 07:45 am, Jeff Trawick wrote:

Expect a patch by Monday night.  I have in-laws in town this weekend.  :-)

> your opinion :)  mine differs; apr_wait_t (definitely should be called
> something else) is simply what information the os makes available
> regarding the dead child process
>
> we don't need the native status code to be what the program returned
> when it exited, because we provide that in a separate parameter
>
> > I am very much against changing the API of an APR function temporarily.
> > Returning the native exit code is not the correct solution to this
> > problem,
> > because that code can't really be used in a portable app.  If the idea
> > is to
> > go to three variables in the function, and then move back to two, then
> > just
> > go straight to two.  If the idea is to stick with three forever, then
> > -1.
>
> no, the idea wasn't to go from 3 to 2; I think all three pieces of
> information are necessary, but if you want to provide one of the
> pieces of information via a different mechanism, then by all means
> show us what you mean
>
> maybe somebody else can jump in here and offer some fresh ideas; maybe
> you (Ryan) would be able to find some time to come up with concrete
> suggestions for how to convey all the necessary information back to
> the app in a politically-correct manner
>
> we can't have an Apache beta until this stuff is resolved (I wouldn't
> veto a beta if just the WCOREDUMP() functionality is missing, but
> there must be a design in place to restore that in the short-term);
> maybe that will be enough to bring in some more attention/ideas

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------