Re: cvs commit: apr/time/win32 time.c

2002-08-05 Thread Ian Holsman
Aaron Bannert wrote: On Sun, Aug 04, 2002 at 06:29:34PM -, [EMAIL PROTECTED] wrote: wrowe 2002/08/04 11:29:33 Modified:include apr_time.h time/unix time.c time/win32 time.c Log: Time in exact ms intervals can be very useful in benchmarking... this

Re: cvs commit: apr configure.in

2002-08-05 Thread Cliff Woolley
On 5 Aug 2002 [EMAIL PROTECTED] wrote: > martin 2002/08/05 02:28:24 > > Modified:.configure.in > Log: > Fix buggy substitution > > Revision ChangesPath > 1.474 +2 -2 apr/configure.in > > Index: configure.in >

Re: cvs commit: apr/time/win32 time.c

2002-08-05 Thread Aaron Bannert
On Sun, Aug 04, 2002 at 09:05:17PM -0500, William A. Rowe, Jr. wrote: > ... Your question should be, if we can't guarantee a certain precision > across the board, how are ab or flood useful? I'd argue they only provide > insufficient resolution, and if there is an api to toggle it, this new > fun

RE: cvs commit: apr/time/win32 time.c

2002-08-05 Thread William A. Rowe, Jr.
At 11:25 PM 8/4/2002, Ryan Bloom wrote: > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] > > At 05:05 PM 8/4/2002, Aaron Bannert wrote: > >On Sun, Aug 04, 2002 at 06:29:34PM -, [EMAIL PROTECTED] wrote: > > > wrowe 2002/08/04 11:29:33 > > > > > > Modified:include apr_time.h >

RE: cvs commit: apr/time/win32 time.c

2002-08-05 Thread Ryan Bloom
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] > > At 05:05 PM 8/4/2002, Aaron Bannert wrote: > >On Sun, Aug 04, 2002 at 06:29:34PM -, [EMAIL PROTECTED] wrote: > > > wrowe 2002/08/04 11:29:33 > > > > > > Modified:include apr_time.h > > >time/unix time.c > >

Re: cvs commit: apr/time/win32 time.c

2002-08-05 Thread William A. Rowe, Jr.
At 05:05 PM 8/4/2002, Aaron Bannert wrote: On Sun, Aug 04, 2002 at 06:29:34PM -, [EMAIL PROTECTED] wrote: > wrowe 2002/08/04 11:29:33 > > Modified:include apr_time.h >time/unix time.c >time/win32 time.c > Log: > Time in exact ms intervals can b

Re: [PATCH] new Resource List interface for apr-util

2002-08-05 Thread Aaron Bannert
On Sat, Aug 03, 2002 at 12:57:12PM -0700, Pier Fumagalli wrote: > It looks great... The only "nitpick" I might have to make (forgot to tell > you earlier) is that instead of apr_reslist_get and apr_reslist_put, those > should be called apr_reslist_acquire and apr_reslist_release, like in locks, > b

[PATCH] apr_poll.h (choosing between the APIs)

2002-08-05 Thread Rob Saccoccio
The following patch incorporates Brian's and Ryan's comments regarding choosing between the two poll APIs. --rob Index: apr_poll.h === RCS file: /home/cvspublic/apr/include/apr_poll.h,v retrieving revision 1.5 diff -u -r1.5 apr_poll

[PATCH] apr_poll.h

2002-08-05 Thread Rob Saccoccio
The following patch to HEAD is suggested so that an empty apr_poll_t struct can safely be created by zeroing a chunk of memory. --rob Index: apr_poll.h === RCS file: /home/cvspublic/apr/include/apr_poll.h,v retrieving revision 1.5 d

[PATCH] pollacc.c poll.c

2002-08-05 Thread Rob Saccoccio
The following patch to HEAD corrects problems with the transparent poll API. Currently, the apr_poll_t struct is handled ambiguously WRT whether its entries are packed or sparse. The brokeness has probably not been apparent because in httpd entries are never removed. The HAVE_POLL path changes ar

RE: [PATCH] poll.c pollacc.c ab.c

2002-08-05 Thread Rob Saccoccio
> I applied part of your fixes [resolving the next issue.] That's the > problem with > submitting a patch of more than one issue... the net error issue was easy > for me to attack at the moment. OK.. New patches on the way. --rob