libapreq's multipart_buffer stuff

[Jim Winstead <ji...@trainedmonkey.com>]

Is it just me, or is it pretty dodgy code? It allocates memory like
its going out of style (it doesn't appear to reuse any of the
buffers it allocates from the pool), resulting in server processes
that balloon up to five times the uploaded file's size. Its also
appears to be flat-out slow because of all the extra work it is
doing.

Just an observation. I (or a coworker if I'm lucky :) will be
rolling up my shirt-sleeves and diving in tomorrow. This is just
my found-the-leak-now-I-get-to-sleep-on-it-and-hope-it-was-fixed-
already-or-I'm-being-dumb mail.

Jim

Re: libapreq's multipart_buffer stuff

[Doug MacEachern <do...@pobox.com>]

On Thu, 24 Feb 2000, Jim Winstead wrote:

> Is it just me, or is it pretty dodgy code? It allocates memory like
> its going out of style (it doesn't appear to reuse any of the
> buffers it allocates from the pool), resulting in server processes
> that balloon up to five times the uploaded file's size. Its also
> appears to be flat-out slow because of all the extra work it is
> doing.

it's pretty dodgy code :)  the multipart buffer code in libapreq is
actually just a translation from CGI.pm's Perl code to C.  notice the
comment: /*XXX: we can optimize this loop*/ 
meaning, I'm aware it's not reusing the buffer, but it's using a subpool
which is cleared at the end of multipart_buffer_fill, each call to that
should be no more than 4k or so.  I have a recent mail (not to the list)
from somebody who experienced the balloon, looked into it, and thinks that
ap_clear_pool() is not working.  anyhow, my plan is to get 1.22 out, then
revisit libapreq, then onto modperl-2.0