You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2003/09/08 21:12:23 UTC
APR::Pool::DESTROY
hi all...
ok, here is a first pass on APR::Pool::DESTROY.
what basically happens here is that DESTROY only calls apr_pool_destroy if
the object on which it is invoked contains magic. so
my $p = APR::Pool->new;
$p->DESTROY;
calls apr_pool_destroy, while
my $p = $r->pool;
$p->DESTROY;
does not. in either case
$p->destroy;
still works, destroying the pool with no checks whatsoever.
in order to add magic to APR::Pool->new() based objects, I had to pull a few
tricks. to avoid messing with the existing typemaps (which wouldn't work
anyway) and the majority of the autogeneration code, what I ended up doing
was adding an additional parameter to apr_functions.map. the additional
parameter, if present, represents a function to place in a CLEANUP section
in WrapXS. this allows the current autogenerated code to keep on working,
while allowing me to manipulate the object just before it is returned to
perl-space. the result ends up looking like this after you follow the
macros around
APR::Pool
mpxs_APR__Pool_new(obj)
SV * obj
CODE:
RETVAL = mpxs_apr_pool_create(aTHX_ obj);
OUTPUT:
RETVAL
CLEANUP:
sv_magic(SvRV(ST(0)), Nullsv, '~', NULL, -1);
I used '~' because that's what modperl_filter uses, which I assumed was a
single character for performance reasons. we can always use something else,
but I didn't think using identical flags would collide in this instance.
anyway, attached is the patch in full. as I said, it's only a first pass,
but it seems to work and is relatively clean. adding the ability to set
CLEANUP sections may be geniuinely useful if we need to do stuff like this
in the future, so I thought it was as good an approach as any.
--Geoff
Re: APR::Pool::DESTROY
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Have you heard of YAGNI[1]? ;)
> *1 - You Aren't Gonna Need It(TM).
obviously, you're not a fan of Field of Dreams...
if you build it, they will come
:)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: APR::Pool::DESTROY
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>> anyway, attached is the patch in full. as I said, it's only a first
>>> pass, but it seems to work and is relatively clean. adding the
>>> ability to set CLEANUP sections may be geniuinely useful if we need
>>> to do stuff like this in the future, so I thought it was as good an
>>> approach as any.
>>
>>
>>
>> If this goes in, we probably need to sync with Gerald, since the plan
>> was to have ExtUtils::WrapXS to replace the current internal
>> implementation when the external one is completed.
>
>
> ok. if we go the apr_pool_userdata_set avenue, then I'm not going to
> worry about the autogeneration stuff. that is, unless you think it will
> be nice to have just in case.
Have you heard of YAGNI[1]? ;)
We can add a link to your patch in the archives, so if we ever need it, we
have it already. However Gerald might want it for the generic module.
*1 - You Aren't Gonna Need It(TM).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: APR::Pool::DESTROY
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> nice
:)
>
>> in order to add magic to APR::Pool->new() based objects, I had to pull
>> a few tricks. to avoid messing with the existing typemaps (which
>> wouldn't work anyway) and the majority of the autogeneration code,
>> what I ended up doing was adding an additional parameter to
>> apr_functions.map. the additional parameter, if present, represents a
>> function to place in a CLEANUP section in WrapXS. this allows the
>> current autogenerated code to keep on working, while allowing me to
>> manipulate the object just before it is returned to perl-space.
>
>
> OK, if setting magic requires tricks, why not use apr_pool_userdata_set
> in mpxs_apr_pool_create for destroy-able objects?
hmph. but implementing the magic was so much fun :)
apr_pool_userdata_set is probably a better way, although I have to see if it
will actually work tomorrow - I was seeing problems with subpools where
is_ancestor and get_parent were _not_ working as expected with subpools, so
I have concerns as to whether the data will persist. but testing will decide :)
>
>> anyway, attached is the patch in full. as I said, it's only a first
>> pass, but it seems to work and is relatively clean. adding the
>> ability to set CLEANUP sections may be geniuinely useful if we need to
>> do stuff like this in the future, so I thought it was as good an
>> approach as any.
>
>
> If this goes in, we probably need to sync with Gerald, since the plan
> was to have ExtUtils::WrapXS to replace the current internal
> implementation when the external one is completed.
ok. if we go the apr_pool_userdata_set avenue, then I'm not going to worry
about the autogeneration stuff. that is, unless you think it will be nice
to have just in case.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: APR::Pool::DESTROY
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> hi all...
>
> ok, here is a first pass on APR::Pool::DESTROY.
>
> what basically happens here is that DESTROY only calls apr_pool_destroy
> if the object on which it is invoked contains magic. so
>
> my $p = APR::Pool->new;
> $p->DESTROY;
>
> calls apr_pool_destroy, while
>
> my $p = $r->pool;
> $p->DESTROY;
>
> does not. in either case
>
> $p->destroy;
>
> still works, destroying the pool with no checks whatsoever.
nice
> in order to add magic to APR::Pool->new() based objects, I had to pull a
> few tricks. to avoid messing with the existing typemaps (which wouldn't
> work anyway) and the majority of the autogeneration code, what I ended
> up doing was adding an additional parameter to apr_functions.map. the
> additional parameter, if present, represents a function to place in a
> CLEANUP section in WrapXS. this allows the current autogenerated code
> to keep on working, while allowing me to manipulate the object just
> before it is returned to perl-space.
OK, if setting magic requires tricks, why not use apr_pool_userdata_set in
mpxs_apr_pool_create for destroy-able objects?
> I used '~' because that's what modperl_filter uses, which I assumed was
> a single character for performance reasons. we can always use something
> else, but I didn't think using identical flags would collide in this
> instance.
'~' is just a general purpose custom magic type, see perlguts (search for
PERL_MAGIC_ext)
> anyway, attached is the patch in full. as I said, it's only a first
> pass, but it seems to work and is relatively clean. adding the ability
> to set CLEANUP sections may be geniuinely useful if we need to do stuff
> like this in the future, so I thought it was as good an approach as any.
If this goes in, we probably need to sync with Gerald, since the plan was to
have ExtUtils::WrapXS to replace the current internal implementation when the
external one is completed.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org