perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [rfc] APR::Table & polymorphic values
Date Thu, 05 Jun 2003 01:19:51 GMT
Joe Schaefer wrote:
> Stas Bekman <stas@stason.org> writes:
> 
> 
>>Joe Schaefer wrote:
>>
>>>Stas Bekman <stas@stason.org> 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.

cool

>>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/table.pm

>>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 CGI.pm'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
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


Mime
View raw message