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 recommendation on how/when/if
we can help get the bucket free lists into the code base?

Thanks,
--Brian






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)  * 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 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 allocator
 change, but the API change part can go ahead and get committed as is
 without the pool change--it would just be a wrapper around malloc until
 the pool change is done, at which point the freelist allocator can be
 dropped in.
 
 When I get back to Charlottesville on Thursday I'll finish up and commit
 whatever part of the buckets change I can depending on the pool patch
 status.
 
 --Cliff
 
 
 --
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
 
 
 
 


-- 
Paul J. Reder
---
The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure.
-- Albert Einstein





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
  the security and robustness of 2.0.

True or false: This refers to an issue where some broken module
   causes the core dir walk to be skipped yet the
   request gets to default handler.

If true: Why is this a showstopper?  Broken modules cause all sorts
 of problems.  If this actually needs to be fixed, it can
 be fixed at any time.

Either way: Any feedback on the comments that JimJag and I put in
the STATUS file?

Is this issue any more complicated than setting a flag
in the last several return OK paths in
ap_directory_walk() and in default_handler() to return
HTTP_FORBIDDEN if the flag isn't set?

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?  Is
there work available for the masses to do?  Can we get the API
changes committed Real Soon Now even if the new behavior isn't yet
ready?

Thanks,

-- 
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...



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 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 allocator
change, but the API change part can go ahead and get committed as is
without the pool change--it would just be a wrapper around malloc until
the pool change is done, at which point the freelist allocator can be
dropped in.

When I get back to Charlottesville on Thursday I'll finish up and commit
whatever part of the buckets change I can depending on the pool patch
status.

--Cliff


--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA





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 allocator
 change, but the API change part can go ahead and get committed as is
 without the pool change--it would just be a wrapper around malloc until
 the pool change is done, at which point the freelist allocator can be
 dropped in.
 
 When I get back to Charlottesville on Thursday I'll finish up and commit
 whatever part of the buckets change I can depending on the pool patch
 status.

Dang, that's exactly what I wanted to hear :)

-- 
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...



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 me?

Changes.  I'm still not sold on the way to handle the allocator ownership.
And allocator locking.

I posted them to the list aswell, btw.

 If not, please go ahead and commit.

If noone else sees problems with it (other than the docstrings missing
from the apr_allocator.h file), I'll commit it in the morning (GMT +1
morning that is).
 
 The bucket freelist change was kind of waiting on the pool allocator
 change, but the API change part can go ahead and get committed as is
 without the pool change--it would just be a wrapper around malloc until
 the pool change is done, at which point the freelist allocator can be
 dropped in.

Cool.
 
 When I get back to Charlottesville on Thursday I'll finish up and commit
 whatever part of the buckets change I can depending on the pool patch
 status.
 
 Dang, that's exactly what I wanted to hear :)

:)

Sander