perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: [mp2] issues with certain serverrec setting methods
Date Sun, 27 Feb 2005 20:07:21 GMT

> But in this case we can't allocate it from the pool, since the object
> that we have is server object, and if we allocate from it, we will get a
> continuous memory leak. The only solution I can see is the one suggested
> earlier by Geoff, which comes from mp1:
>   SV *server_admin = perl_get_sv("Apache::ServerRec::ServerAdmin", TRUE);
>   sv_setsv(server_admin, ST(1));
>   obj->server_admin = SvPVX(serever_admin);
> i.e. we create a superficial perl variable to make sure that the value
> will stick around if the original scalar is modified or destroyed.

I don't think we need to worry about restoring elements that are native to
the server_rec - these are official record slots, ones that aren't really
messed with all that much, and ones that don't necessarily cause much harm
if the multi-request span isn't fully understood.

document_root is, of course, different because we're messing with the
internal configuration data of http_core _and_ because that value is used
during translation of lots of requests.

> Anybody sees a better solution?

I see your point that we can't allocate from the server pool each time, and
I guess why the current situation is bad is because the PV will go out of
scope at the end of the request leaving a bad pointer around, right?

still, I don't see that we need to go the whole
_modperl_private::apache_server_admin route for these fields.  error_fname
is one that comes to mind as being especially useless to modify - it might
be (and is) useful to read, but it's useless at request time since the
error_log fd is opened and forgotten about long before then.  maybe it makes
sense to offer write access during open_logs or something, but at that point
the PV wouldn't go out of scope, right?

> If we go with this one, should we use some obscure name space for this
> kind of stashing? We don't really want to support more APIs, do we? and
> using the "Apache::ServerRec::ServerAdmin" is something that people will
> discover and certainly use. Which of course could be a good thing too,
> as it'll be faster, but on the other hand it won't be set unless a user
> has modified $s->server_admin. That's why I think it should be hidden
> into something like: $_modperl_private::apache_server_admin

I'm not opposed to that.  I was just offering some thoughts off the top of
my head :)

> Ideas?
> Finally if we go with that solution, should we use it for
> $r->document_root as well, so it'll behave more like mp1 did? in other
> thread we agreed that it's a goodness to restore it at the end of each
> request. I think we should stick to that solution.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message