Re: apr_proc_wait status codes.

2001-09-20 Thread Kevin Pilch-Bisson
On Thu, Sep 20, 2001 at 12:33:06PM -0700, Ryan Bloom wrote: > On Thursday 20 September 2001 11:53 am, William A. Rowe, Jr. wrote: > > IMHO, these discrepancies should be hidden by our API. E.g. we aught to > > provide both an apr_status_t (with the return results matched up across > > platforms, a

RE: apr_proc_wait status codes.

2001-09-20 Thread Bill Tutt
The status should be the result of the WEXITSTATUS macro for Unix then. STILL_ACTIVE will never be returned on Win32, since we just got finished waiting for the process to have exited. Bill "Though we are not now that strength that in old days moved Earth and Heaven, that which we are we are; On

Re: apr_proc_wait status codes.

2001-09-20 Thread Ryan Bloom
On Thursday 20 September 2001 11:53 am, William A. Rowe, Jr. wrote: > IMHO, these discrepancies should be hidden by our API. E.g. we aught to > provide both an apr_status_t (with the return results matched up across > platforms, and added to our APR_statuses lists) and the processes' exit > code.

Re: apr_proc_wait status codes.

2001-09-20 Thread Kevin Pilch-Bisson
On Thu, Sep 20, 2001 at 01:53:54PM -0500, William A. Rowe, Jr. wrote: > IMHO, these discrepancies should be hidden by our API. E.g. we aught to > provide both an apr_status_t (with the return results matched up across > platforms, and added to our APR_statuses lists) and the processes' exit code.

Re: apr_proc_wait status codes.

2001-09-20 Thread William A. Rowe, Jr.
IMHO, these discrepancies should be hidden by our API. E.g. we aught to provide both an apr_status_t (with the return results matched up across platforms, and added to our APR_statuses lists) and the processes' exit code. APR_SUCCESS would mean the process _has_ terminated, here's the exit code

RE: apr_proc_wait status codes.

2001-09-20 Thread Bill Tutt
That would seem to make lots of sense. Bill "Though we are not now that strength that in old days moved Earth and Heaven, that which we are we are; One equal temper of heroic hearts made weak by time and fate but strong in will to strive, to seek, to find, and not to yield." -- Tennyson -

[PATCH] fix cleanups in cleanups (Was Re: New post-log-transaction hook?)

2001-09-20 Thread Aaron Bannert
On Wed, Sep 19, 2001 at 12:27:35PM -0700, Jon Travis wrote: > BZzzzt. The attached code registers a cleanup from within a cleanup, and > does so 'correctly'. See the program attached at the bottom, which behaves > incorrectly. It is simple code, but not knowing that a given > function registers

Re: [PATCH] Addresses broken OC data

2001-09-20 Thread Ryan Bloom
On Thursday 20 September 2001 10:25 am, William A. Rowe, Jr. wrote: This is the right solution, +1. Ryan > The OC child logic is broken WRT the 'id' field. I noticed the bogosity > grepping for Win32 casts. > > We have no reason _not_ to simply carry the apr_proc_t * instead of 'id'. > > Commen

[PATCH] Addresses broken OC data

2001-09-20 Thread William A. Rowe, Jr.
The OC child logic is broken WRT the 'id' field. I noticed the bogosity grepping for Win32 casts. We have no reason _not_ to simply carry the apr_proc_t * instead of 'id'. Comments? Bill brokenoc.patch Description: Binary data

apr_proc_wait status codes.

2001-09-20 Thread Kevin Pilch-Bisson
Hi all, I'm the one sort of reponsible for asking for return codes in apr_proc_wait (and thanks for how quickly they were added), but now I am concerned about their portability. My MSDN page for GetExitCodeProcess says it retrurns either STILL_ACTIVE or the return code for the process. Meanwhi

Re: [PATCH] Add return value to apr_proc_wait

2001-09-20 Thread Greg Stein
On Wed, Sep 19, 2001 at 11:14:00PM -0700, Justin Erenkrantz wrote: >... > How would this patch work? This seems like a reasonable change. > > Win32 doesn't implement wait_all from what I can tell, so I'm not > sure how to get the return value. OtherBill or Ryan can probably > figure this out. -

Re: apr_table_t (was: Re: Release time?)

2001-09-20 Thread Greg Stein
On Wed, Sep 19, 2001 at 09:55:56PM -0700, Justin Erenkrantz wrote: > On Wed, Sep 19, 2001 at 09:48:30PM -0700, Brian Pane wrote: > > Following the pattern of the apr_hash_t iterator is fine with me, too. > > > > But I just noticed a small problem with the apr_hash_t iterator: > > > > APR_DECLAR

[PATCH] Add return value to apr_proc_wait was Re: FW: Updating svn.collab.net

2001-09-20 Thread Justin Erenkrantz
On Thu, Sep 20, 2001 at 12:37:55AM +0200, Sander Striker wrote: > [forwarded thread from [EMAIL PROTECTED] > > -Original Message- > From: Kevin Pilch-Bisson [mailto:[EMAIL PROTECTED] > Sent: 19 September 2001 21:46 > To: [EMAIL PROTECTED] > Cc: Greg Stein; Sander Striker; [EMAIL PROTECTED]

Re: apr_table_t (was: Re: Release time?)

2001-09-20 Thread Justin Erenkrantz
On Wed, Sep 19, 2001 at 09:48:30PM -0700, Brian Pane wrote: > Following the pattern of the apr_hash_t iterator is fine with me, too. > > But I just noticed a small problem with the apr_hash_t iterator: > > APR_DECLARE(void) apr_hash_this(apr_hash_index_t *hi, const void **key, >

Re: apr_table_t (was: Re: Release time?)

2001-09-20 Thread Brian Pane
Ian Holsman wrote: On Wed, 2001-09-19 at 14:28, Justin Erenkrantz wrote: On Wed, Sep 19, 2001 at 12:25:36PM -0700, Brian Pane wrote: The original approach that I posted was a traditional iterator object: typedef struct apr_table_iter_t apr_table_iter_t; apr_table_iter_t * apr_table_iter_make(apr_

[STATUS] (apr-util) Wed Sep 19 23:45:13 EDT 2001

2001-09-20 Thread Rodent of Unusual Size
APRUTIL LIBRARY STATUS: -*-text-*- Last modified at [$Date: 2001/07/13 03:51:20 $] Release: 2.0a9 : released December 12, 2000 RELEASE SHOWSTOPPERS: * Need apu_compat.h to track the latest renames Status: someone want to step up to diff na

[STATUS] (apr) Wed Sep 19 23:45:10 EDT 2001

2001-09-20 Thread Rodent of Unusual Size
APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: -*-text-*- Last modified at [$Date: 2001/09/19 15:27:16 $] Release: 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2