perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [rfc] APR::Table & polymorphic values
Date Thu, 05 Jun 2003 01:19:51 GMT
Joe Schaefer wrote:
> Stas Bekman <> writes:
>>Joe Schaefer wrote:
>>>Stas Bekman <> writes:
>>>>Still, once user tries to modify the data, what happens to meta-data?
>>>>When COW is performed, does it copy the whole thing or just whatever
>>>>was pointed by SvCUR?
>>>Doesn't matter.  The point is that if there's an Apache::Request::Table
>>>that subclasses APR::Table, it doesn't have to *reimplement everything*
>>>in APR::Table.  It can just fixup the return values before they are
>>>returned, like this:
>>>  package Apache::Request::Table;
>>>  use base 'APR::Table';
>>>  sub get {
>>>     if (wantarray) {
>>>        return map {fixup_sv($_)} &APR::Table::get;       }
>>>    else {
>>>        return fixup_sv(scalar &APR::Table::get);
>>>    }
>>>  }
>>>The only XSUB we'd need to maintain in the subclass is fixup_sv().
>>>But if APR::Table uses newSVpvn, Apache::Request::Table would need
>>>to *completely reimplent all* the APR::Table XSUBS.
>>So we really are concerned about FETCH, and never about STORE?
> For APR::Tables, that's right- the copy/merge callbacks (which I'm 
> confident apr will adopt) will take care to add some appropriate
> metadata during STORE.


>>What if you use mpxs_apr_table_do to fixup the elements on the first
>>FETCH? Would that be a bad approach? 
> Not sure what you have in mind.

you can run filter on all pairs in the table, see t/response/TestAPR/

>>The problem is that I still don't understand what do you need that
>>meta data for and how is it used.
>   1) the perl-glue for apreq will finally be able to handle embedded 
>      nul characters,
>   2) we can duplicate's overloading of params, since file-uploads
>      are just params with a non-NULL bucket-brigade attached.
>   3) we can do lots of cool stuff with cookie values, too.

Any examples of how is it used?

> Here's another idea that is safe, and should work for everyone:
> just add a magic pointer to the original (char *) and keep using
> newSVpv():
>   MP_INLINE static SV *mpxs_apr_table_str_2sv(pTHX_ const char *str)
>   {
>         SV *sv = newSVpv(str, 0);
>         sv_magic(sv, Nullsv, PERL_MAGIC_ext, str, 0);
>         return sv_2mortal(sv);
>   }
> This way Apache::Request::Table can get at the original string
> via mg->mg_ptr, so it just needs to maintain an sv_fixup XSUB.

Can you ensure that apr won't relocate the string? why not pointing at the 
newly copied sv's PV?

I can't see where the meta data is in str. Is it before str?

> If this looks ok, I'll try to conjure up a patch :-)


Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

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

View raw message