On Monday 03 September 2001 18:49, Cliff Woolley wrote:
> On Mon, 3 Sep 2001, Ryan Bloom wrote:
> > I seriously dislike adding an SMS to every bucket.  I believe we are
> > much better off just creating a per-thread free bucket list.  That
> > keeps us from ever calling free while dealing with a request, and over
> > time, we will stop calling malloc.
>
> Okay, let's examine this option for a minute.  There are two ways to do
> this: either the buckets code handles it or httpd handles it.  If the
> buckets code handles it, you have to do the thread lookups we talked about
> before, which is bad.  So that pretty much means it's up to the httpd to
> handle it.  So what's the easiest way to do that?

The bucket code has to handle this.  The easy way to do this, is to pass in
an integer which corresponds to which bucket list to use.

As long as the bucket code handles the list, all the rest of the problems just
dissappear.  Instead of calling malloc(), you call apr_get_bucket(), which
grabs it from the free list.  Instead of calling free(), you call 
apr_done_with_bucket().

The only problem is the type specific buckets.  These just get their own lists. 
 The
error bucket from HTTP should continue to use malloc/free, because we are 
already
in an error condition, so performance isn't a big deal.

If we modify the bucket API a tad, and pass a pool in to the bucket create 
steps (not
sure how feasible this is until I have time to really examine the code), we can 
allocate
the buckets out of the thread pool.  Now, in perchild, all of the buckets 
allocated for
a given thread are automatically cleaned up when that thread dies.

No extra public API's, at all.  We just add two static functions, and a couple
of variable to store the free lists.  We can remove SMS from the server 
altogether,
and if things go well, we can even remove SMS from APR.  Having two different
memory API's is just making things complex IMNSHO.

Ryan
______________________________________________________________
Ryan Bloom                              [EMAIL PROTECTED]
Covalent Technologies                   [EMAIL PROTECTED]
--------------------------------------------------------------

Reply via email to