Re: global variables and reparsing question (low priority ;)
forget about mod_perl for a moment. yes, true, Perl's built-in require
will not reload a module if it's already in %INC. but that's doesn't mean
a Perl environment cannot un-cache that entry so it will be reloaded.
consider the code below, pretend that loop is a long-lifetime server,
Tk type application, vi or emacs with Perl embedded:
use Module::Reload ();
do {
Module::Reload-check;
require Foo;
} while (STDIN);
Module::Reload checks the mtime of Foo.pm (and all loaded modules) on
disk, if it has changed since the last time it was require'd, it will be
reloaded. this is perfectly valid Perl, the language supports this
feature. i'm quite certain your code be changed to adapt to such an
environment.
Re: global variables and reparsing question (low priority ;)
On Fri, 26 May 2000, Marc Lehmann wrote: I know this and I have no problems with that (as I made very clear in my last mail). But when mod_perl requires special programming techniques this does not mean that code not using that techniques is "broken anyway", as dougm said, at least not in perl. It might be "broken code", but then the language is not perl (where the problematic technique is documented to work in perltoot). when i said 'broken', that is shorthand for, you need to change your code so it can deal with being reloaded. which, is valid in the Perl language. As I explained I was getting defensive simply because _not_ all are friends here. I am still defensive because calling somebody else's code broken should not be done so lightly. you shouldn't take offense to what i said, it was not directed at you alone, i've said it plenty of times before you brought it up. just as i've said using 'exit()' is broken, along with any other code that makes assumptions about it's calling environment. What happened, if you go back and read the thread, is that I had a question and had a very hard time explaining what I actually meant (because my initial mails were simply not verbose enough on the problem). Many responses (especially the private ones) were very aggressive, so "we are all friends" is a myth. i didn't see any "aggressive" responses on the list, if mine came across that way, i apoligize, i certainly didn't mean to. i've spent a great deal of time trying to help people on this list over the past 4 years and trying to make mod_perl better at the same time. my responses tend to be short and to the point to optimize my time, i'm a really friendly guy in person :) Since this is my first contact with modperl, however, this just means that I wasn't able to adjust myself to the tone on (and around) the modperl mailinglist.. Next time I will simply ignore most of the responses. i think the tone in general on this list is *very* positive and friendly, much more so than the few other lists i subscribe to. don't let one misunderstanding discourage you, harsh words are very rare here.
Re: global variables and reparsing question (low priority ;)
On Thu, Jun 01, 2000 at 11:59:53AM -0700, Doug MacEachern [EMAIL PROTECTED] wrote: will not reload a module if it's already in %INC. but that's doesn't mean a Perl environment cannot un-cache that entry so it will be reloaded. consider the code below, pretend that loop is a long-lifetime server, Doing that, however, breaks code that uses documented and recommended techniques (see perltoot for the best example). My problem is not that it is possible to actively break code within normal perl, this is easy in any language. Module::Reload checks the mtime of Foo.pm (and all loaded modules) on disk, if it has changed since the last time it was require'd, it will be reloaded. this is perfectly valid Perl, the language supports this feature. You miss a very large point: Modules are not just files containing perl code. One of the features of modules is that, how often you might use them, they are only loaded once (unlike "do EXPR", for example). Sure, you can load modules in different ways, even in ways that break them, and the code still runs under perl (that is, without syntax error), but this has not much to do with perl's concept of modules anymore. i'm quite certain your code be changed to adapt to such an environment. It's easy, I just have to kick my ass each time I want to use a lexical for data abstraction and use a package variable instead, with only the exception that I have to be very careful that I never re-use the same name. This is quite difficult for code that resides in many files (package variables are, of course, global to the whole package not just the file or the block), but not unsolvable. You see, my first problem was misunderstanding (or not understanding) what apache does during the "module initialization phase", and how "reload" is defined (namely by not deleting the package). I assumed that a "fresh restart" would imply a fresh perl interpreter, or at least a fresh package, not just loading the code over the old one, preserving it. While I am not sure why PerlFreshRestart is implemented in this misleading manner, I can definitely live with that, as it is an option that can be turned off, which is much more than one can expect (namely nothing at all!), and, given that this is not considered a bug but a limitation with mod_perl (spec. that single option), can be worked around consistently (as it is relatively minor). The biggest problem with PerlFreshRestart is that it causes bugs which are very difficult to find and that might only be found after a lot of debugging, as the problem might be in a third-party module you have never seen the source code of. The more important aspects of mod_perl of course work fine, and this is what counts most. So consider that totally solved to my satisfaction. (Indirectly) calling my code broken (ah, you probably see where the problem is, now ;), however, will require some very good arguments from your side, which you didn't give so far. Especially I'd like to hear why perltoot (and others) actively encourage these "broken" programming techniques that enable data hiding and definitely work with "perl modules": Surely I can load a .pm file using other methods, like "do", or by nuking the %INC entry, but changing the behaviour of "use" so drastically changes the notion of "modules" as well. In my opinion, using a different way of loading modules than the documented one, a way that breaks modules that work fine under the documented mechanism, does not magically turn recommended code practises into broken code practises. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: global variables and reparsing question (low priority ;)
On Thu, 1 Jun 2000, Marc Lehmann wrote: It's easy, I just have to kick my ass each time I want to use a lexical for data abstraction and use a package variable instead, with only the exception that I have to be very careful that I never re-use the same name. This is quite difficult for code that resides in many files (package variables are, of course, global to the whole package not just the file or the block), but not unsolvable. The simplest thing is to just not use PerlFreshRestart or Apache::StatINC (which works in a similar way). These are generally a bad idea for production servers anyway, due to their effect on shared memory, and mostly exist to ease development, although in your case they had the opposite effect. There are several warnings about mysterious problems caused by PerlFreshRestart in the guide, and my impression is that most people simply avoid it altogether. If you don't use these your code should work just fine, lexicals, accessors, and all. - Perrin
Re: global variables and reparsing question (low priority ;)
On Fri, May 26, 2000 at 10:33:15AM -0400, Geoffrey Young [EMAIL PROTECTED] wrote: mod_perl sometimes requires special perl coding guidelines, due in part to the way mod_perl works with and within apache. I know this and I have no problems with that (as I made very clear in my last mail). But when mod_perl requires special programming techniques this does not mean that code not using that techniques is "broken anyway", as dougm said, at least not in perl. It might be "broken code", but then the language is not perl (where the problematic technique is documented to work in perltoot). For example, you shouldn't do things under Registry that are otherwise ok Exactly what I said. These things are otherwise ok, but mod_perl requires special treatment. mod_perl. that doesn't make mod_perl a dialect of perl, However, you can't claim that mod_perl _is_ perl and at the same time claim that perfectly valid perl code is broken. Either it's broken code in the mod_perl dialect or it's valid code not working due to environment constraints. actually, it makes perfect sense, if you think of it in apache/mod_perl I can understand why it happens, if you mean that. Wether it makes perfect sense is, unfortunately, not so clear to me. and, there's no reason to get real argumentative or defensive about any of this, Marc - we're all friends here, in modest persuit of the same things :) As I explained I was getting defensive simply because _not_ all are friends here. I am still defensive because calling somebody else's code broken should not be done so lightly. What happened, if you go back and read the thread, is that I had a question and had a very hard time explaining what I actually meant (because my initial mails were simply not verbose enough on the problem). Many responses (especially the private ones) were very aggressive, so "we are all friends" is a myth. Since this is my first contact with modperl, however, this just means that I wasn't able to adjust myself to the tone on (and around) the modperl mailinglist.. Next time I will simply ignore most of the responses. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: global variables and reparsing question (low priority ;)
On Tue, May 23, 2000 at 10:05:01AM +0200, Marc Lehmann wrote: On Tue, May 23, 2000 at 12:56:28AM -0500, Autarch [EMAIL PROTECTED] wrote: On Tue, 23 May 2000, Marc Lehmann wrote: stable (mod_perl really is very unstable for large applications). Apart Wow, I wish you'd warned me before I did several large applications using mod_perl. Fortunately, they haven't experienced any mod_perl related Well, add XML::Parser, some large and twisted perl modules (like XML::XSLT), do a lot of things dynamically (recompiling etc..) and apache segfaults quite a lot, at random times, and even with some weird effects (adding a comment makes httpd segfault, removing it and it works again). Fortunately, once you found a source form where httpd starts up, mod_perl seems to run fine for a long time. Did you follow the thread about XML::Parser's bug WRT apache embedding? You need to change the configure arguments to apache if you want this to work... Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/
Re: global variables and reparsing question (low priority ;)
On Wed, 24 May 2000, Marc Lehmann wrote:
You must be kidding here!!! Using lexicals on package level is broken??? If
it is broken, then _why_ is it recommended programming practise in perl (see
perltoot for example)?
i'm not kidding. i don't understand whay you mean by 'using lexicals on
package level is broken'. i see no problem with that. maybe you could
post an example, your first one, as you said yourself, was broken. here's
a tiny example that is not broken:
% cat MyTest.pm
package MyTest;
my $x = 0;
sub inc_x {
$x++;
}
sub print_x {
print "x=$x\n";
}
print "MyTest loaded\n";
1;
% cat test.pl
for (1..2) {
delete $INC{'MyTest.pm'};
require MyTest;
for (1..5) {
MyTest::inc_x();
MyTest::print_x();
}
}
% perl test.pl
MyTest loaded
x=1
x=2
x=3
x=4
x=5
MyTest loaded
x=1
x=2
x=3
x=4
x=5
are you expecting different results?
and, like i said, i realize that certain modules make assumptions that
they will only be loaded once in the same process and that re-parsing them
can uncover subtle problems. but i still consider such assumptions to be
broken.
Re: global variables and reparsing question (low priority ;)
On Thu, May 25, 2000 at 11:58:38AM -0700, Doug MacEachern [EMAIL PROTECTED] wrote:
You must be kidding here!!! Using lexicals on package level is broken??? If
it is broken, then _why_ is it recommended programming practise in perl (see
perltoot for example)?
i'm not kidding. i don't understand whay you mean by 'using lexicals on
package level is broken'.
here is my module, in very terse pseudocode:
=
package mymodule;
my some"globals";
sub functiousing someglobals {
}
now load other code (in some kind of xml) and compile it into it's
package, UNLESS the package already exists.
==
And this obviously breaks for the newly compiled code. The caching,
unfortunately, is very important. Surely I could make an exception when
running under mod_perl with PerlFreshRestart, but that code runs nicely in
other environments, since the apache bits have been abstracted away. Read
below.
and, like i said, i realize that certain modules make assumptions that
they will only be loaded once in the same process and that re-parsing them
can uncover subtle problems. but i still consider such assumptions to be
broken.
Sorry, but reparsing is never done by perl itself (it explicitly says so),
so mod_perl clearly is not acting like perl.
So, in in the mod_perl dialect of perl, modules that work fine in perl
magically break on restarts. This is because mod_perl "restarts" by
fooling the perl interpreter to think it hasn't seen _some_ parts of the
program(s) and tries to reload all on top of it.
What's confusing here is the term "FreshRestart", which doesn't do
anything like a "fresh restart".
The reason this is important to me is not because I couldn't make an
exception to my code for apache - it's the real world, so hacks are
necessary in many cases anyway - but because what's broken is mod_perls
idea of "fresh restarting" by cheating the perl interpreter rather than my
code.
Now that I know what's going on it's not a big deal, but if you call
my code broken you should have rather good arguments on the basis of
the perl language and protgramming, not because mod_perl does some very
undocumented things differently to perl itself.
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: global variables and reparsing question (low priority ;)
Huh? Why is "do" a bad thing Do is bad because it is called every time, even if you've already executed You are confused about the two different forms of do. The do BLOCK form I used has nothing to do with the do EXPR form you seem to be confused about. perldoc -f do explains the differences quite in detail. flag to keep from compiling again and checking $@ yourself, so you're getting around these problems, but the file form of do is generally a red flag. This is just as saying "division is a bad thing in general, because it let's you try to divide by zero". Of course you could abuse do, but you should read about the different forms of do in the perl documentation where it explains what do is for, and what it isn't for. (let's direct followup discussion about perl to private mail, thanks) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: global variables and reparsing question (low priority ;)
On Tue, May 23, 2000 at 08:22:59PM -0700, Doug MacEachern [EMAIL PROTECTED] wrote: If this were true, it would be very bad. If there is no technical need to do this "half-reloading" then it should definitely be turned off. it is off by default, you turned it on with 'PerlFreshRestart On' Which had undocumented side effects, breaking valid perl. (No problem, if everywhere were documented... :) It breaks perfectly valid perl code, creating some kind of it's not breaking code, it's exposing broken code. if a module can't then the module is broken. You must be kidding here!!! Using lexicals on package level is broken??? If it is broken, then _why_ is it recommended programming practise in perl (see perltoot for example)? Sorry, you can say that this and that programming technique is invalid under PerlFreshRestart, which is entirely ok, and just means that mod_perl != perl (which it is in other details as well). Calling recommended perl programming techniques "broken", however, is something entirely different :-| Especially since this results in _very_ subtle problems, in where, for example, splitting a function into two functions might render a program not working for reasons well outside the understanding of many perl programmers. In any case, mod_perl is fine to do this. It would have bitten me much later if it didn't do this double-parsing at loading time. This, however, is an incompatibility from mod_perl to standard perl, not "broken". What is broken is the notion of "deleting from INC" is equivalent to "unloading a module". -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: global variables and reparsing question (low priority ;)
[EMAIL PROTECTED] (Marc Lehmann) wrote: flag to keep from compiling again and checking $@ yourself, so you're getting around these problems, but the file form of do is generally a red flag. This is just as saying "division is a bad thing in general, because it let's you try to divide by zero". As a math teacher, I must point out that dividing by zero really *is* bad, so perhaps we really *should* outlaw division. Let people multiply by the reciprocal. One of my students divided by zero and the rest of us had to clean up the mess for weeks afterwards. Pulp everywhere! Much worse than trying to take the square root of a negative number, which just gives you a Pavlovian shock and sends you on your way. ( =), of course) ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: global variables and reparsing question (low priority ;)
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).
Re: global variables and reparsing question (low priority ;)
On Tue, May 23, 2000 at 12:56:28AM -0500, Autarch [EMAIL PROTECTED] wrote: On Tue, 23 May 2000, Marc Lehmann wrote: stable (mod_perl really is very unstable for large applications). Apart Wow, I wish you'd warned me before I did several large applications using mod_perl. Fortunately, they haven't experienced any mod_perl related Well, add XML::Parser, some large and twisted perl modules (like XML::XSLT), do a lot of things dynamically (recompiling etc..) and apache segfaults quite a lot, at random times, and even with some weird effects (adding a comment makes httpd segfault, removing it and it works again). Fortunately, once you found a source form where httpd starts up, mod_perl seems to run fine for a long time. I, too, used mod_perl for large projects _before_ and they ran stable (== Apache::Registry). But the picture changes quite a bit when I started to write my own mod_perl handler and to use the Apache::API extensively. But this is very off-topic, at leats to my real concern (double parsing). OTOH, the instability could very well be related to this as well. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: global variables and reparsing question (low priority ;)
On Tue, May 23, 2000 at 12:27:58PM +0800, Gunther Birznieks [EMAIL PROTECTED]
wrote:
replace my $global with use vars qw($global); and your problem should
disappear.
If you had read my mail you would have known that I do not search for a
workaround. While in this simple example it is possible to create a package
variable instead of the lexical, it is ugly (I mean, the variable is now
visible everywhere). In other circumstances it is very hard to usea package
variable instead, e.g.:
my $v;
sub xxx { $v }
my $v;
sub yyy { $v }
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: global variables and reparsing question (low priority ;)
On Tue, 23 May 2000, Marc Lehmann wrote: On Tue, May 23, 2000 at 12:56:28AM -0500, Autarch [EMAIL PROTECTED] wrote: On Tue, 23 May 2000, Marc Lehmann wrote: stable (mod_perl really is very unstable for large applications). Apart Wow, I wish you'd warned me before I did several large applications using mod_perl. Fortunately, they haven't experienced any mod_perl related Well, add XML::Parser, some large and twisted perl modules (like XML::XSLT), do a lot of things dynamically (recompiling etc..) and apache segfaults quite a lot, at random times, and even with some weird effects (adding a comment makes httpd segfault, removing it and it works again). Fortunately, once you found a source form where httpd starts up, mod_perl seems to run fine for a long time. Hmm... AxKit does all this, and is very stable for me, and I've only had a couple of reports of segfaults, none of which went unsolved as far as I know... Ah well, there are still stability issues, but that's C programming for you ;-) -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: global variables and reparsing question (low priority ;)
On Mon, May 22, 2000 at 11:24:10PM -0700, Perrin Harkins [EMAIL PROTECTED] wrote: business about being parsed twice only applies to Apache's config file and Perl sections in it, not to your modules. A little followup: Looking at the mod_perl source, I see that INC is tinkered with in a lot of places. Removing modules from %INC would result in exactly the kind of behaviour I described. Unfortunately I don't know under which circumstances this happens, so I am still egaer to find out why and when this happens, and how to shield my application against that. I also forgot (uh-oh) to describe my system configuration (sorry, it was 5am): Currently, I use perl5.6 + mod_perl-1.23, but I see the behaviour since at least perl5.005_03 + mod_perl-1.21. The system is linux + apache 1.3.12 (problem seen since apache-1.3.9). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: global variables and reparsing question (low priority ;)
On Tue, May 23, 2000 at 09:26:13AM +0100, Matt Sergeant [EMAIL PROTECTED] wrote: Hmm... AxKit does all this, and is very stable for me, and I've only had a couple of reports of segfaults, none of which went unsolved as far as I know... OK. To be fair, I am not 100% sure wether it's an mod_perl problem. The same application works fine in standalone (e.g. SpeedyCGI) mode. It also seems to be related to high perl parsing activity (the application parses at least 60k of perl source per second ;) So, as to not clobber this dicussion with any claims of mod_perl stability, let's consider mod_perl rock-solid, since the I can handle the stability problems (segfaults do not occur on requests, but either after them or while startup, so users aren't affected) What I cannot handle is the reparsing of my modules :( -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: global variables and reparsing question (low priority ;)
[EMAIL PROTECTED] (Marc Lehmann) wrote:
=
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.
You know, if I didn't know any better, I'd say that you're simply setting
$global (not the best name) in one httpd child, but of course it's not getting
set in the others.
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.
I don't think I believe that. Nothing gets parsed twice except http
configuration files. Is this file used inside perl sections of config
files, maybe?
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: global variables and reparsing question (low priority ;)
helu. Marc Lehmann wrote: 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). I'm not sure this makes sense for your case, but it might help, so... From "Writing Apache Modules with Perl and C", p59 "When the server [apache] is restarted, the configuration and module initialization phases are called again. To ensure such restarts will be uneventful, Apache actually runs these two phases twice during server startup just to check that all modules can survive a restart." signed, gustavo
Re: global variables and reparsing question (low priority ;)
On Tue, May 23, 2000 at 10:08:46AM -0700, Gustavo Duarte [EMAIL PROTECTED] wrote: I'm not sure this makes sense for your case, but it might help, so... It probably makes a lot of sense. Thanks! "When the server [apache] is restarted, the configuration and module initialization phases are called again. To ensure such restarts will be uneventful, Apache actually runs these two phases twice during server startup just to check that all modules can survive a restart." If this were true, it would be very bad. If there is no technical need to do this "half-reloading" then it should definitely be turned off. It breaks perfectly valid perl code, creating some kind of "mod_perl-language-subset". At least _I_ lost days of debugging to find out about these subtle differences to standard perl. (And this also means that some CPAN modules would need to be patched to run with mod_perl). Or in other words: mod_perl should either do it cleanly or not at all. Or have a very good reason to break code ;) Does the book say what "module initialization phase" means, and how one can work around that? (Apart from patching _every_ module with a hack like the one I posted)? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: global variables and reparsing question (low priority ;)
On Tue, 23 May 2000, Marc Lehmann wrote: At leats in the example I sent in there is no sign of any closure. There is a closure, and this might be the thing that's making trouble for you, or at least part of it. This is a closure: that example is only a closure if it's compiled by Apache::Registry, which, is not in this case.
global variables and reparsing question (low priority ;)
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 |
|
Re: global variables and reparsing question (low priority ;)
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/
Re: global variables and reparsing question (low priority ;)
On Tue, 23 May 2000, Marc Lehmann wrote: stable (mod_perl really is very unstable for large applications). Apart Wow, I wish you'd warned me before I did several large applications using mod_perl. Fortunately, they haven't experienced any mod_perl related problems. Just a fluke, I guess. Anyway... -dave /*== www.urth.org We await the New Sun ==*/
