On 31 Aug 2000 [EMAIL PROTECTED] wrote:
> Btw: I've been playing with the keep-alive stuff you left lying around
> in Connection.xs. The naive implementation I made seems to work fine,
> once the headers are sent to the client. Are you planning to add them
> in the next mod_perl release?
yo
Doug,
The get_client_block part of the patch works just fine - haven't had a chance
to confirm the rest of it.
Thanks again.
--
Joe Schaefer
[EMAIL PROTECTED]
SunStar Systems, Inc.
Doug,
Thanks for clearing this up for me - great explanation!
I'll let you know how your patch works out.
Btw: I've been playing with the keep-alive stuff you left lying around
in Connection.xs. The naive implementation I made seems to work fine,
once the headers are sent to the client. Are
On 31 Aug 2000 [EMAIL PROTECTED] wrote:
> Doug,
>
> Sorry to belabor a dull issue, but I'm not sure I'm getting my point across.
no problem, this is important stuff to understand.
> Most of the troubles I've run across in the mod_perl and libapreq code
> have to do with attempts to allocate m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 31 Aug 2000 [EMAIL PROTECTED] wrote:
> I'm not sure what SvGROW does, but if it involves a malloc
> without freeing the old buffer, you've got the same problem as before.
> Each time the perl version of get_client_block is called,
> SvGROW will
Doug,
Sorry to belabor a dull issue, but I'm not sure I'm getting my point across.
Most of the troubles I've run across in the mod_perl and libapreq code
have to do with attempts to allocate memory resources for buffers
at runtime. That's exactly what the BUFF API does, right?
What I'm seeing
On 31 Aug 2000 [EMAIL PROTECTED] wrote:
> The mod_perl implementation of get_client_block has a memory leak.
> The following patch should keep it from from pissing in r->pool.
thanks joe. i don't see how allocating from r->pool is a "leak", but
yeah, it is a waste of resources since Perl is goi
