I don't quite understand what you're trying to do, but what you have
here is a closure and it looks like you want a real global instead.
(man perlref if "closure" doesn't ring a bell.) Some of your language
makes it look like you may have some confusion between global and
lexicals. At any rate, "do" is nearly always a bad thing and the
business about being parsed twice only applies to Apache's config file
and <Perl> sections in it, not to your modules.
- Perrin
Marc Lehmann wrote:
>
> While I understand how my problem happens, it just caught me again
> (letting me debug another two hours), and so I wanted to ask why this
> peculiar behaviour is really necessary.
>
> But straight to the point. If I have a module like this:
>
> =============================================================================
> package othermodule;
>
> my $global = 5;
>
> sub set_global {
> $global = shift;
> }
> =============================================================================
>
> And use this from another module:
>
> =============================================================================
> othermodule::set_global 7;
> =============================================================================
>
> Then, to my surprise, _sometimes_ the $global will be set, and sometimes not.
>
> The reason for this seems to be that othermodule is parsed twice: Once
> during configuration parsing and once later. The first time it is parsed,
> $global is created and bound to ste_global. Other modules that call the
> function get a reference to it cimpiled in.
>
> Then, when the file is parsed again, _another_ instance of $global gets
> created, and another instance of set_global is compiled. Now there are two
> versions of set_global, two versions of $global, and which one gets called
> very much depends on random factors.
>
> To my pity, _some_ global (non-lexical) variables also get cleared, but
> not in all packages.
>
> Now, since this is really hard to debug (the order of function declaration
> within the same file and wether the funciton is exported or not, and
> wether there are other callers outside the file etc...
>
> To remedy this, many of my modules (the bad point is that even modules I have
> no control over suffer from this problem) start with something like this:
>
> =============================================================================
> if (!defined $PApp::Apache::compiled) { eval do { local $/; <DATA> };
> die $@ if $@ } 1;
> __DATA__
>
> #line 6 "(PApp::Apache source)"
> =============================================================================
>
> This mostly remedies the situation. The only "side effects" that I found
> so far is that my httpds reuqire much _less_ memory and run _much_ more
> stable (mod_perl really is very unstable for large applications). Apart
> from expected semantics of global lexical variables.
>
> So.... my very own problem is solvable (either by using package variables
> or that ugly but working trick above). Third-party modules (e.g. from
> CPAN) however, still suffer from this problem, and due to my dumbness I
> fall into that trap again and again.
>
> And so my question is: why does this behaviour exist, and why is it
> necessary (the documents I saw so far only told me that this "has
> something to do with apache's configuration file parsing", which doesn't
> explain much, especially as it does seem unnecessary).
