perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [MP2 Patch] Bug ? Recursion in parsing of PerlSection
Date Tue, 27 May 2003 05:01:47 GMT
Philippe M. Chiasson wrote:
> On Tue, 2003-05-27 at 12:00, Stas Bekman wrote:
> 
>>Philippe M. Chiasson wrote:
>>[...]
>>
>>>Is evaluated in Apache::ReadConfig's namespace, even if it does nothing.
>>>
>>>Once again Apache::PerlSections is called in with Apache::ReadConfig as
>>>the namespace
>>>
>>>This handler will once again see
>>>
>>>@Apache::ReadConfig::include = "foo.conf";
>>>
>>>and here starts the recursion.
>>>
>>>
>>>This is a hairy problem indeed. I realized this partially in the past,
>>>when re-introducing PerlSaveConfig but didn't think of this particular
>>>recursive possibility.
>>>
>>>The way I see it, there is only a few ways to proprely fix this.
>>>
>>>1. To use one _extra_ namespace to save the config into, if
>>>PerlSaveConfig is specified, and delete or move elements from
>>>Apache::ReadConfig as it is being processed.
>>>
>>>2. To use automatically-generated namespaces for each <Perl > sections,
>>>like ModPerl::Registry, like Apache::ReadConfig::blocknnn or something.
>>>
>>>I personally prefer solution #2.
>>>
>>>Ideas/suggestions ? If not, I'll probably give a shot at implementing #2
>>>sometime this week.
>>
>>Do you have to process again the include directive? 
> 
> 
> Well, if I PerlSection was smart enough it could treat @Include
> directives as a special case, but that wouldn't solve the whole problem.
> 
> 
>>If not, why not use the 
>>same solution as used by require, which stores name=>path of loaded files in 
>>%INC. I don't know where you currently store the processed result of include, 
>>but if you lose it, why not store it in %Apache::ReadConfig::INC, with key 
>>being the included filename and value the result of the include? Though need 
>>to ensure that we have no duplication when two files with indentical names 
>>(but located at different paths) are included. Should probably resolve these 
>>to a full path? or append the parent's path?
> 
> 
> Yes, I thought along those lines, but the simplest problem with this
> approach is this (unrelated to first problem, it's a second problem)
> 
> <Perl >
> push @Alias = [ '/foo', '/bar' ];
> </Perl>
> 
> And later on
> 
> <Perl >
> 1;
> </Perl>
> 
> Will cause a warning about one Alias shadowing another one.
> 
> The core reason why <Perl > blocks are a bit broken right now is
> because multiple <Perl > sections add to the same namespace (if
> SaveSections is on, or if @include is used), and when the PerlSection
> handler kicks in , it has no way to differentiate between the content it
> has processed before vs. the new stuff.
> 
> I thougth about many ways of moving stuff as it's being processed, but
> it would be quite complex, as it's all recursive and all.
> 
> The following patch does work nicely for me though.
> 
> It puts each <Perl > block in it's own namespace, and keeps feeding them
> to the handler as usual. It all works fine. When it's time to have
> Apache::PerlSections->Dump(), it'll be just a matter of iterating over
> all those namespaces, striping them out before printing them.
> 
> And since Dump() has not been ported yet (mea culpa), I figured this
> change wouldn't break anything.
> 
> Thoughts ?

I see at least two drawbacks with this approach:

- waste of memory, namespaces aren't cheap (at least use modperl_mgv)
- if you add a new <Perl > above the existing ones, this code will break:

> -    ok not exists $Apache::ReadConfig::Location{'/perl_sections'};
> +    ok not exists $Apache::ReadConfig::1::Location{'/perl_sections'};

why not monitoring what information was seen already using some other method? 
e.g. push those chunks into an array and flatten it when you need and you 
still have a control on what you have seen and what not? in the worst case you 
can store unprocessed flattened sections, then undef everything in 
Apache::ReadConfig, and process it again. Will that work?

__________________________________________________________________
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