Re: dumb questions on a couple of the current 2.0 showstoppers

2002-03-20 Thread Brian Pane
Paul J. Reder wrote: > Cliff, > > I know you are busy, is there something I can do to help with this > since the pools stuff is in now? Does it still just need to have > the malloc replaced and the code tested? > > I'm happy to help in any way possible. Me too. Cliff, what's your recommendati

Re: dumb questions on a couple of the current 2.0 showstoppers

2002-03-19 Thread Paul J. Reder
Cliff, I know you are busy, is there something I can do to help with this since the pools stuff is in now? Does it still just need to have the malloc replaced and the code tested? I'm happy to help in any way possible. Cliff Woolley wrote: > On Tue, 12 Mar 2002, Jeff Trawick wrote: > > >>2)

RE: dumb questions on a couple of the current 2.0 showstoppers

2002-03-12 Thread Sander Striker
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick > Sent: 13 March 2002 00:00 > Cliff Woolley <[EMAIL PROTECTED]> writes: > >> The pool allocator change is done AFAIK -- Sander, are there any other >> changes that need to be made above the ones in the patch you sent

Re: dumb questions on a couple of the current 2.0 showstoppers

2002-03-12 Thread Jeff Trawick
Cliff Woolley <[EMAIL PROTECTED]> writes: > The pool allocator change is done AFAIK -- Sander, are there any other > changes that need to be made above the ones in the patch you sent me? If > not, please go ahead and commit. > > The bucket freelist change was kind of waiting on the pool allocat

Re: dumb questions on a couple of the current 2.0 showstoppers

2002-03-12 Thread Cliff Woolley
On Tue, 12 Mar 2002, Jeff Trawick wrote: > 2) * API changes planned for 2.0 that should happen before the > GA release: > * Free lists for bucket allocation > * Pool allocator change > > Can anybody comment on the current status of either of these? The pool allocat

dumb questions on a couple of the current 2.0 showstoppers

2002-03-12 Thread Jeff Trawick
1) * If any request gets to the core handler, without a flag that this r->filename was tested by dir/file_walk, we need to 500 at the very end of the ap_process_request_internal() processing. This provides authors of older modules better compatibility, while still improving