apr and pools

2002-03-22 Thread Dagfinn Aarvaag
Hi, We are using apr in a product that we try to develope for the telecom operators. I have a problem with a growing memory pool when I create a server socket and accepts tcp connections on the server socket. It seams that the memory pool used for the server socket grows for each accepted tcp

Re: cvs commit: apr/dso/unix dso.c

2002-03-22 Thread Jeff Trawick
Pier Fumagalli [EMAIL PROTECTED] writes: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: rbb 02/03/20 11:45:02 + *) Load libraries if they not MH_BUNDLE, but if they are not, it + just attempts to link them as shared libs. + [Pier Fumagalli [EMAIL PROTECTED]] F***

[PATCH] apr_file_time_set() (was: Re: [PATCH] Adding an apr_utime() function)

2002-03-22 Thread Robert Simonson
I've taken a shot at redoing this. Is this more what you're thinking? Thanks. Rob Simonson [EMAIL PROTECTED] apr/file_io/unix/filestat.c === --- filestat.c.old Thu Mar 14 11:20:04 2002 +++ filestat.cFri Mar 22 09:49:34

RE: cvs commit: apr/dso/unix dso.c

2002-03-22 Thread Ryan Bloom
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: rbb 02/03/20 11:45:02 + *) Load libraries if they not MH_BUNDLE, but if they are not, it + just attempts to link them as shared libs. + [Pier Fumagalli [EMAIL PROTECTED]] F*** YEAH! :) First patch into core APR...

Re: cvs commit: apr/atomic/os390 atomic.c

2002-03-22 Thread Greg Ames
[EMAIL PROTECTED] wrote: -apr_atomic_t apr_atomic_add(apr_atomic_t *mem, apr_uint32_t val) +apr_int32_t apr_atomic_add(apr_atomic_t *mem, apr_int32_t val) Ian, Should we change the 2nd input param to apr_int32_t everywhere? This occured to me when I used -1 there to implement

Re: [PATCH] apr_file_time_set() (was: Re: [PATCH] Adding an apr_utime() function)

2002-03-22 Thread William A. Rowe, Jr.
At 10:00 AM 3/22/2002, you wrote: To: William A. Rowe, Jr. [EMAIL PROTECTED] Cc: dev@apr.apache.org, Jeff Trawick [EMAIL PROTECTED] I've taken a shot at redoing this. Is this more what you're thinking? Thanks. Rob Simonson [EMAIL PROTECTED] Terrific! I'll commit as soon as I have a free minute

Re: cvs commit: apr configure.in

2002-03-22 Thread Greg Ames
[EMAIL PROTECTED] wrote: gregames02/03/22 13:41:47 Modified:.configure.in Log: get rid of the -g compiler flag on OS/390, unless this is a debug or maintainer mode build. Does anyone have a problem with doing the same on all platforms? I will commit such a fix

Re: cvs commit: apr configure.in

2002-03-22 Thread Aaron Bannert
On Fri, Mar 22, 2002 at 05:05:46PM -0500, Greg Ames wrote: [EMAIL PROTECTED] wrote: gregames02/03/22 13:41:47 Modified:.configure.in Log: get rid of the -g compiler flag on OS/390, unless this is a debug or maintainer mode build. Does anyone have a

Re: cvs commit: apr configure.in

2002-03-22 Thread Jeff Trawick
Greg Ames [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: gregames02/03/22 13:41:47 Modified:.configure.in Log: get rid of the -g compiler flag on OS/390, unless this is a debug or maintainer mode build. Does anyone have a problem with doing the same

Re: cvs commit: apr configure.in

2002-03-22 Thread Jim Jagielski
Jeff Trawick wrote: If backtraces posted by users to our mailing lists and our bug databases will be even a little easier to look at, then I am strongly in favor of keeping the -g as a default. If somebody is worried about that amount of space then let them strip the executable files.