[EMAIL PROTECTED] wrote:
stas2004/01/28 18:44:33
Modified:xs/APR/Brigade APR__Brigade.h
Log:
avoid a memory leak if flatten() croaks by moving newSV until after croak.
Watch out for the clear and hidden behind macros croak calls after perl vars
were created w/o being made mortal
Geoffrey Young wrote:
You are correct. I didn't realize that pflatten was a cheat (plus scary
comment in apr_brigade_pflatten: 'XXX This is dangerous beyond
belief..'). I thought it didn't call apr_brigade_length, but did flatten
at one pass. I should have looked at the source. Sorry about that.
> You are correct. I didn't realize that pflatten was a cheat (plus scary
> comment in apr_brigade_pflatten: 'XXX This is dangerous beyond
> belief..'). I thought it didn't call apr_brigade_length, but did flatten
> at one pass. I should have looked at the source. Sorry about that.
np. I guess w
Geoffrey Young wrote:
Stas Bekman wrote:
Doh! since my suggested change drops the use of apr_brigade_pflatten,
all this magic is no longer needed. just use the grow macro like all
other functions do and pass SvPVX to flatter. and whoah, no longer we
need the pool object! that's a goodness.
which
Stas Bekman wrote:
> Doh! since my suggested change drops the use of apr_brigade_pflatten,
> all this magic is no longer needed. just use the grow macro like all
> other functions do and pass SvPVX to flatter. and whoah, no longer we
> need the pool object! that's a goodness.
which makes it look
Doh! since my suggested change drops the use of apr_brigade_pflatten, all this
magic is no longer needed. just use the grow macro like all other functions do
and pass SvPVX to flatter. and whoah, no longer we need the pool object!
that's a goodness.
Here's the reworked patch (against cvs):
Ind
At 10:54 -0800 1/28/04, Stas Bekman wrote:
Geoffrey Young wrote:
Good. So should we
split /[\r\n]/, $config
if it's a scalar,
we have Apache::CRLF to take the guesswork out, or alternatively we could
use $/.
I don't think it makes any difference, we need to do it in C.
Is this so efficiency boun
Geoffrey Young wrote:
but this is the same as newSVpvn(buffer, length);. You still allocate
the buffer twice (second time in mpxs_sv_grow which calls SvGROW). I've
attached the adjusted patch (of only this file), which allocates memory
only once. we should make it into a macro.
well, I was just d
> but this is the same as newSVpvn(buffer, length);. You still allocate
> the buffer twice (second time in mpxs_sv_grow which calls SvGROW). I've
> attached the adjusted patch (of only this file), which allocates memory
> only once. we should make it into a macro.
well, I was just doing it the wa
-8<-- Start Bug Report 8<--
1. Problem Description:
This is probably the weirdest thing I have ever witnessed.
Try the following "test.pl":
#!/usr/bin/env perl -w
use strict;
# the
my $html = <<"END_OF_HTML";
title
Hello
END_OF_HTML
print "$html\n";
Geoffrey Young wrote:
ok, both of these issues are addressed in the attached patch.
looks good, a few efficiency fixes are due
pcalloc shouldn't be used, unless you really need to 0 all the bytes. palloc
is faster.
-return newSVpvn(buffer, length);
+mpxs_sv_grow(data, length);
+SvP
Geoffrey Young wrote:
Enrico Sorcinelli wrote:
Hi all,
I've this strange (for me) behaviour (Apache 2.0.48/mod_perl 1.9912).
In MP2 (Registry scripts and handlers) I cannot retrieve, directly from %ENV,
the additional environvment variables that I pushed with $r->subprocess_env
method (for examp
> Geoff, I think you are taking this idea of matching the C API a bit too
> far away.
I don't think so. besides, if I weren't here pulling it back a bit, you'd
be off creating another API altogether :)
> If the C API was simple people would have used C to write their handlers
> in first place.
> Can you please remind me what was the mp1 behavior on that? We need to
> match it. Things are complicated in mp2, because the C environ struct is
> detached from perl's %ENV, so there is a lot of extra work to do to
> think %ENV and $r->subprocess_env
as I said in another response, IIRC in mp1
>
> Not only not intuitive, but wrong. Consider this case: some function
> returns the wanted amount of chars to slurp, let's say it decides that
> it doesn't want any more chars and sets $wanted to 0 and you passed it
> to $bb->flatten($pool, $wanted); now instead of getting an empty string,
>
Elizabeth Mattijsen wrote:
At 10:54 -0800 1/28/04, Stas Bekman wrote:
Geoffrey Young wrote:
Good. So should we
split /[\r\n]/, $config
if it's a scalar,
we have Apache::CRLF to take the guesswork out, or alternatively we
could
use $/.
I don't think it makes any difference, we need to do it in
Geoffrey Young wrote:
I don't think it makes any difference, we need to do it in C.
then use the CRLF define - it ought to be platform neutral no matter where
it's implemented :)
sure
__
Stas BekmanJAm_pH --> Just An
Geoffrey Young wrote:
[EMAIL PROTECTED] wrote:
stas2004/01/27 22:02:50
Modified:lib/ModPerl TestRun.pm
.Changes
Log:
make 't/TEST -startup_timeout secs' working (previously user's value
was ignored)
this change causes a fresh checkout not to build. even wi
Geoffrey Young wrote:
Stas Bekman wrote:
As some of you may have followed the discussions here, we are scared to
death from users using the wrong pools and shooting themselves into the
foot.
well, some are more scared than others ;)
we will see
Really, what happens is that we take the cool eas
> I don't think it makes any difference, we need to do it in C.
then use the CRLF define - it ought to be platform neutral no matter where
it's implemented :)
--Geoff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additiona
> %ENV is not tied to $r->subprocess_env such that %ENV
> and $r->subprocess_env always look the same.
actually, I take that back. it looks like they are (at least for perl-script).
this is probably a bad idea - we should probably rely on ap_add_cgi_vars
(etc) for populating %ENV, and not join
Geoffrey Young wrote:
Good. So should we
split /[\r\n]/, $config
if it's a scalar,
we have Apache::CRLF to take the guesswork out, or alternatively we could
use $/.
I don't think it makes any difference, we need to do it in C.
_
> Thanks, I've applied this patch and it seems to solve Registry problems: it
> populates %ENV with additional vars.
> Moreover CGI/mod_cgi, SSI (and so on) work fine... :-)
cool.
>
> However, handler still doesn't have access to %ENV's additional vars (but this
> isn't a really problem for me)
On Wed, 28 Jan 2004 09:47:35 -0500
Geoffrey Young <[EMAIL PROTECTED]> wrote:
Hi Geoff,
> the exchange between the subprocess_env table and %ENV only happens once
> per-request. to me, it looks like this once is on the first Perl*Handler
> callback. for the most part, I think this is ok, since h
[EMAIL PROTECTED] wrote:
> stas2004/01/27 22:02:50
>
> Modified:lib/ModPerl TestRun.pm
>.Changes
> Log:
> make 't/TEST -startup_timeout secs' working (previously user's value
> was ignored)
this change causes a fresh checkout not to build. even with
> Good. So should we
>
> split /[\r\n]/, $config
>
> if it's a scalar,
we have Apache::CRLF to take the guesswork out, or alternatively we could
use $/.
> and not if it's an ARRAY ref?
yeah, sounds good.
--Geoff
-
To un
Enrico Sorcinelli wrote:
> Hi all,
>
> I've this strange (for me) behaviour (Apache 2.0.48/mod_perl 1.9912).
>
> In MP2 (Registry scripts and handlers) I cannot retrieve, directly from %ENV,
> the additional environvment variables that I pushed with $r->subprocess_env
> method (for example in a
Stas Bekman wrote:
> As some of you may have followed the discussions here, we are scared to
> death from users using the wrong pools and shooting themselves into the
> foot.
well, some are more scared than others ;)
> Really, what happens is that we take the cool easy Perl and bring
> back th
Hi all,
I've this strange (for me) behaviour (Apache 2.0.48/mod_perl 1.9912).
In MP2 (Registry scripts and handlers) I cannot retrieve, directly from %ENV,
the additional environvment variables that I pushed with $r->subprocess_env
method (for example in a Translation or HeaderParser phase).
In
29 matches
Mail list logo
