replace my $global with use vars qw($global); and your problem should
disappear.
At 05:40 AM 5/23/00 +0200, 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).
>
>Thanks a lot for any feedback ;)
>
>--
> -----==- |
> ----==-- _ |
> ---==---(_)__ __ ____ __ Marc Lehmann +--
> --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
> -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
> The choice of a GNU generation |
> |
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/
