Re: mod_perl + UNIVERSAL
On Tue 12-Feb-2002 at 04:02:47PM -0500, Perrin Harkins wrote: A list of things I've noticed: * If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. This is how perl works. You are not allowed to have two different modules with the same name loaded in the same interpreter. If you can't deal with that, maybe you should consider using an environment like Mason or Embperl which allow a page-based approach closer to PHP, rather than using perl's package namespace. I know that this is how perl works... in the context of mod_perl though, in some cases it'd be less hassle to be able to have persistent perl processes isolated per script or per host... Anyway if mod_perl 2.0 allows a pool of perls on a per-host basis as you said, then it'd be a great plus! * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! Global variables are variables without scope. They are not cleaned up by definition. If you want variables that go out of scope, use lexicals. If you have legacy code that depends on mod_cgi behavior to work, use Apache::PerlRun which clears globals on each request. Apache::PerlRun is far too slow (I don't wanna recompile 18.000 lines of Perl code on each request, thanks :-)). Global variables are useful to store objects that can be accessed anywhere. The only way out is to manually undef everything on each request... I suppose it's not so bad, but I'm just a lazy bastard thus I need to complain :-) * Perl garbage collector should be smarter (okay, that may not be a mod_perl issue). C geeks out there, ain't it possible to compile a version of Perl with a better GC? Doug has talked about doing something with this in mod_perl 2 to help clean up memory taken for lexicals, but it's not definite. And yes, this is really a Perl issue, not a mod_perl one. Yeah Perl not cleaning cyclic references is a pain. And WeakRef is a horrible hack :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM
Re: mod_perl + UNIVERSAL
The thing is I am getting some weird behaviour where one application seems to be getting code from the other. In theory this isn't possible with the separated namespaces. I suspect my UNIERVSAL use is the problem. Can anyone verify this? Is it a known problem? Is there any way around it? To my knowledge, the only namespace which is separated is package main. I don't know about you guys, but I think it would be great if mod_perl could be as painless as mod_php. Don't get me wrong, I think that PHP as a language is absolutely fubar, however mod_php is fast, secure, isp friendly and does not have so many problems as mod_perl. A list of things I've noticed: * If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! * Perl garbage collector should be smarter (okay, that may not be a mod_perl issue). C geeks out there, ain't it possible to compile a version of Perl with a better GC? * Despite numerous heroic efforts, HTTP HEAD requests are still screwed! Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry doesn't work with redirects and 404's (I get like two headers and 3 bodies for 404's. Now that's verbose :-)) These are the - painful - issues I discovered during the last 6 month of intensive mod_perl coding. I hope they'll be fixed at some point because mod_perl could be so popular if they were! Allright I'll stop whining and go back to some coding ;-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM
Re: mod_perl + UNIVERSAL
Jean-Michel Hiver wrote: [snip] A list of things I've noticed: * If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. And who's to say that a custom module that you write can't end up on CPAN??? Or even as a Standard module? There may be ways of fiddling with @INC to do what you want, but it would be much easier if you, the developer, took care to make unique namespaces for your different projects... * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! If you want them reset each time, then reset them to undef manually. The alternative is having Apache reload the entire module from scratch on every request - and then you may as well be using mod_cgi.. [snip] * Despite numerous heroic efforts, HTTP HEAD requests are still screwed! Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry doesn't work with redirects and 404's (I get like two headers and 3 bodies for 404's. Now that's verbose :-)) No real mod_perl problem on that - that's a problem (or maybe intentional functionality?) in Apache::Registry and Apache::HEADRegistry... These are the - painful - issues I discovered during the last 6 month of intensive mod_perl coding. I hope they'll be fixed at some point because mod_perl could be so popular if they were! I dunno... I think that the main reason mod_perl isn't as popular as mod_php is because PHP is SSI based, making it more appetizing to lots of developers who don't have such good access to the server, or who don't want to understand the internals of Apache module writing (remember that that's the real point of mod_perl: to write Apache modules in Perl instead of C), whereas mod_perl means pre-writing modules and having to reload the server (or use a top-heavy module like Apache::StatInc) every time you want to change your code. Of course, that's the power of mod_perl over mod_php. And I know that personally, it's why I use it. As to the non-ISP friendliness disadvantage, that's a critical issue, but I think it's being re-analyzed for mod_perl 2.0 Just my two agorot (a bit less than $0.005 now, I think, although due to that the smallest currency here is actually _5_ agorot :-) ) Issac
Re: mod_perl + UNIVERSAL
On Tue, 12 Feb 2002 14:15:37 +1100
Morton-Allen, Matthew [EMAIL PROTECTED] wrote:
However both applications make use of the UNIERVSAL package to create
universally accessible methods (to return the current database handle for
example) within the application.
You don't need UNIVERSAL for the purpose. Try import().
package Foo;
our @ISA = qw(Exporter);
our @EXPORT = qw(get_dbh);
sub get_dbh { ... }
package main;
use Foo; # will import get_dbh()
my $dbh = get_dbh;
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: mod_perl + UNIVERSAL
* If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. And who's to say that a custom module that you write can't end up on CPAN??? Or even as a Standard module? There may be ways of fiddling with @INC to do what you want, but it would be much easier if you, the developer, took care to make unique namespaces for your different projects... Consider this. I develop a piece of software in Perl which is quite big. Therefore it's split into a horde of modules. Now do these modules changes between versions? Yes (bug fixes, improvements, API changes, etc). Do the modules name change? Nope! As a result I had to amend the software so that it can run multiple websites. But then if there is a need to change the logic of just one site I can't just go and change one module because it would change it for everything else. In other words it'd be nice to be able to run different versions of the same software for different websites on the same server (via virtual hosts). And that doesn't work. Besides this: with @INC to do what you want, but it would be much easier if you, the developer, took care to make unique namespaces for your different projects... is highly bullshit. I am not the only developer on the planet. For instance there is a CPAN module called HTML::Tree. But there is also another module on the web called HTML_Tree, which installs itself as HTML::Tree. The developer does not want to rename his module (I understand that). Even if I install / compile the module locally, mod_perl is going to screw everything up! Great! * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! If you want them reset each time, then reset them to undef manually. I think this is wrong. Variables should be reinitialized by default, or persistent if specified otherwise in some config file. * Despite numerous heroic efforts, HTTP HEAD requests are still screwed! Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry doesn't work with redirects and 404's (I get like two headers and 3 bodies for 404's. Now that's verbose :-)) No real mod_perl problem on that - that's a problem (or maybe intentional functionality?) in Apache::Registry and Apache::HEADRegistry... intentional functionality. I though that bugs were called features, but this is even better. I'll have to remember this one :- don't want to understand the internals of Apache module writing (remember that that's the real point of mod_perl: to write Apache modules in Perl instead of C), whereas mod_perl means pre-writing True, however the real point of Apache::Registry is to run unaltered CGI scripts under mod_perl and it just doesn't work properly does it? Of course, that's the power of mod_perl over mod_php. And I know that personally, it's why I use it. As to the non-ISP friendliness disadvantage, that's a critical issue, but I think it's being re-analyzed for mod_perl 2.0 Do you know where to find mod_perl 2 related info on the web? I'd be interested in knowing what's it gonna be. Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM
Re: mod_perl + UNIVERSAL
Jean-Michel Hiver wrote: * If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. And who's to say that a custom module that you write can't end up on CPAN??? Or even as a Standard module? There may be ways of fiddling with @INC to do what you want, but it would be much easier if you, the developer, took care to make unique namespaces for your different projects... Consider this. I develop a piece of software in Perl which is quite big. Therefore it's split into a horde of modules. Now do these modules changes between versions? Yes (bug fixes, improvements, API changes, etc). Do the modules name change? Nope! As a result I had to amend the software so that it can run multiple websites. But then if there is a need to change the logic of just one site I can't just go and change one module because it would change it for everything else. In other words it'd be nice to be able to run different versions of the same software for different websites on the same server (via virtual hosts). And that doesn't work. TMTOWTDI: Make all of your global (base) functionality wrapped into some OO Perl module, and then if you need to change specific behavior for certain apps, you can easily subclass it. If the main functionality has to be changed, change the parent object; if it has to be changed for a specific web-app, dump it into the inheritted class. That's one solution, and I'm sure there are others... Besides this: with @INC to do what you want, but it would be much easier if you, the developer, took care to make unique namespaces for your different projects... is highly bullshit. I am not the only developer on the planet. For instance there is a CPAN module called HTML::Tree. But there is also another module on the web called HTML_Tree, which installs itself as HTML::Tree. The developer does not want to rename his module (I understand that). Even if I install / compile the module locally, mod_perl is going to screw everything up! Great! That's the developer's fault. I'm sorry. But that's why you're _supposed_ to check in with [EMAIL PROTECTED] before deciding on your modules namespaces. Just because _another_ developer is using a taken namespace doesn't make it right enough that special pains have to be made to get around it. And if they _did_, that would be a Perl problem, not a mod_perl related issue! For example, how would you get the CPAN Html::Tree to work in the same script as this other HTML::Tree? You couldn't, because the Perl interpreter wouldn't know what to do with it. Same here! * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! If you want them reset each time, then reset them to undef manually. I think this is wrong. Variables should be reinitialized by default, or persistent if specified otherwise in some config file. What if I _want_ a variable that stays consistant across a specific child process' lifetime? Right now, a way _exists_ of resetting variables, but how would you propose to keep them static if your idea was implemented? * Despite numerous heroic efforts, HTTP HEAD requests are still screwed! Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry doesn't work with redirects and 404's (I get like two headers and 3 bodies for 404's. Now that's verbose :-)) No real mod_perl problem on that - that's a problem (or maybe intentional functionality?) in Apache::Registry and Apache::HEADRegistry... intentional functionality. I though that bugs were called features, but this is even better. I'll have to remember this one :- ;-) don't want to understand the internals of Apache module writing (remember that that's the real point of mod_perl: to write Apache modules in Perl instead of C), whereas mod_perl means pre-writing True, however the real point of Apache::Registry is to run unaltered CGI scripts under mod_perl and it just doesn't work properly does it? No. That's Apache::PerlRun. Apache::Registry usually needs some tweaking to run properly. There's plenty of information about that in the guide under the HUGE portion devoted to CGI_to_mod_perl_porting (or even in the special manpage under the same name). Of course, that's the power of mod_perl over mod_php. And I know that personally, it's why I use it. As to the non-ISP friendliness disadvantage, that's a critical issue, but I think it's being re-analyzed for mod_perl 2.0 Do you know where to find mod_perl 2 related info on the web? I'd be interested in knowing what's it gonna be. Not really sure. I asked about that and got the current state of the mod_perl 2 docs from CVS, but I, too,
Re: mod_perl + UNIVERSAL
* Despite numerous heroic efforts, HTTP HEAD requests are still screwed! Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry doesn't work with redirects and 404's (I get like two headers and 3 bodies for 404's. Now that's verbose :-)) No real mod_perl problem on that - that's a problem (or maybe intentional functionality?) in Apache::Registry and Apache::HEADRegistry... actually, on this particular issue I think it is a design problem on mod_perl's part. if anyone is interested, he's my analysis... I think the problem here is that mod_perl sets the assbackward flag when setting headers via send_cgi_header() (which CGI.pm does). the assbackward flag means that Apache will forego sending headers itself. I think I understand Doug's logic in the code: send_cgi_header() prints the headers directly to the client, instead of setting $r-headers_out-set() and letting Apache do it, which is more like the way mod_cgi works. anyway, r-assbackward is a hack that mod_perl uses in a few places. the problem with messing with r-assbackward is that it really signifies an HTTP/0.9 response, for which GET is the only option, not HEAD. so... the normal Apache logic that cuts the body of the response out of a HEAD request (by checking r-header_only) is circumvented when r-assbackward is set. And, since Apache sends the body for REDIRECT and other errors (and not mod_perl) Apache doesn't know to _not_ send the body. get it? the routines in question are ap_send_error_response() in http_protocol.c and send_cgi_header() in Apache/Apache.pm (which calls mod_perl_sent_header() in mod_perl.c, which sets r-assbackward). I'm not sure if it is possible to easily work around this, but that's what I've come up with so far if anyone else wants to tackle this particular issue... --Geoff
Re: mod_perl + UNIVERSAL
I think the problem here is that mod_perl sets the assbackward flag when setting headers via send_cgi_header() (which CGI.pm does). Is this only an issue when using CGI.pm or PerlSendHeader then? I seem to recall having no trouble doing this from a normal handler. - Perrin
Re: mod_perl + UNIVERSAL
Perrin Harkins wrote: I think the problem here is that mod_perl sets the assbackward flag when setting headers via send_cgi_header() (which CGI.pm does). Is this only an issue when using CGI.pm or PerlSendHeader then? I seem to recall having no trouble doing this from a normal handler. yeah, from what I can tell, CGI.pm is the only issue with HEADRegistry.pm. print Location: foo seems to work fine. I don't think PerlSendHeader is the problem - I tried it both ways IIRC. Apache::Registry doesn't handle HEAD requests at all, I don't think - HEADRegistry.pm respects $r-header_only and runs into this problem with redirects, Registry doesn't even try. for normal mod_perl handlers it shouldn't be an issue - it's up to the handler to check $r-header_only and take appropriate action, which is typically setting headers using $r-headers_out and returning an appropriate value. after a while, my mind started swimming in circles and I gave up :) --Geoff
Re: mod_perl + UNIVERSAL
However both applications make use of the UNIERVSAL package to create universally accessible methods (to return the current database handle for example) within the application. Better to put those into a package of your own and call them with fully-qualified names, or import them as Tatsuhiko demonstrated. The thing is I am getting some weird behaviour where one application seems to be getting code from the other. In theory this isn't possible with the separated namespaces. I suspect my UNIERVSAL use is the problem. There is just one Perl interpreter per process, and thus one namespace and one UNIVERSAL package. If you try to create two different versions of the sub UNIVERSAL::foo() it won't work: there can be only one. This is true for any package name, actually. If you need separate subs, name them differently or put them in separate packagaes. - Perrin
Re: mod_perl + UNIVERSAL
A list of things I've noticed: * If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. This is how perl works. You are not allowed to have two different modules with the same name loaded in the same interpreter. If you can't deal with that, maybe you should consider using an environment like Mason or Embperl which allow a page-based approach closer to PHP, rather than using perl's package namespace. It is also true that mod_perl 2 will have additional support for doing fancy things with virtual hosts, like having separate pools of interpreters (and thus separate namespaces) for each virtual host. See http://perl.apache.org/~dougm/modperl_2.0.html for more. I am not the only developer on the planet. For instance there is a CPAN module called HTML::Tree. But there is also another module on the web called HTML_Tree, which installs itself as HTML::Tree. One person's mistake hardly justifies a massive change in the way namespaces work in perl. Anyway, that was fixed, thanks to Terrence Brannon. His HTML::Seamstress module replaces the former HTML_Tree. * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! Global variables are variables without scope. They are not cleaned up by definition. If you want variables that go out of scope, use lexicals. If you have legacy code that depends on mod_cgi behavior to work, use Apache::PerlRun which clears globals on each request. * Perl garbage collector should be smarter (okay, that may not be a mod_perl issue). C geeks out there, ain't it possible to compile a version of Perl with a better GC? Doug has talked about doing something with this in mod_perl 2 to help clean up memory taken for lexicals, but it's not definite. And yes, this is really a Perl issue, not a mod_perl one. - Perrin
RE: mod_perl + UNIVERSAL
* Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! Try looking into the way mod_perl hooks into the apache configuration. This may work for setting site wide constants globals depending on how you use them. You can then set different values for virtual hosts or even allow directives to be set in '.htaccess' files. * Perl garbage collector should be smarter (okay, that may not be a mod_perl issue). C geeks out there, ain't it possible to compile a version of Perl with a better GC? There really is no reason to cleanup the globals since they are still referenced and in memory. Perhaps you can consider an interface around your code which can handle the cleanup and such of any variables. You could also set a 'cleanup' handler to 'unload' the module from the process when it is completed or even 'undef' specific variables. That way you can clear out the namespace and then other scripts calling the same named module but from a different path can actually load it.
RE: mod_perl + UNIVERSAL
This is what I thought but I am not getting behaviour that indicates this.
To explain.
I have two applications, a forums program and a basic portal. Both of these
run on the same server under virtual servers. Both .pl's have a section
where they switch into the UNIVERSAL package and setup some global routines.
For example:
in forums.pl
sub main {
# init type stuff
}
sub loader {
}
package UNIVERSAL;
sub print_error {
# Global error logging routine
}
The portal.pl has the equivalent. The problem I am getting is that under
some as of yet unknown circumstances the print_error from portal is coming
up in forums. But, and here's the bit that's confusing me, under normal
operating they seem to coexist fine. forums.pl gets it's print_error (i.e.
somewhere is calling $self-print_error) and portal.pl get's it's. How is it
possible for this to happen at all? If the UNIVERSAL namespace is shared I
would have thought one or the other (the last one?) would get the
print_error sub and the other loses out but at some point they seem to
coexist just fine. Whilst at some other point they as expected and one gets
the others. Any theories?
Matt.
-Original Message-
From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 13 February 2002 7:45 AM
To: Morton-Allen, Matthew; [EMAIL PROTECTED]
Subject: Re: mod_perl + UNIVERSAL
However both applications make use of the UNIERVSAL package to create
universally accessible methods (to return the current database handle for
example) within the application.
Better to put those into a package of your own and call them with
fully-qualified names, or import them as Tatsuhiko demonstrated.
The thing is I am getting some weird behaviour where one application seems
to be getting code from the other. In theory this isn't possible with the
separated namespaces. I suspect my UNIERVSAL use is the problem.
There is just one Perl interpreter per process, and thus one namespace and
one UNIVERSAL package. If you try to create two different versions of the
sub UNIVERSAL::foo() it won't work: there can be only one. This is true for
any package name, actually. If you need separate subs, name them
differently or put them in separate packagaes.
- Perrin
RE: mod_perl + UNIVERSAL
Hi all, On Tue, 12 Feb 2002, Stathy G. Touloumis wrote: There really is no reason to cleanup the globals since they are still referenced and in memory. Perhaps you can consider an interface around your code which can handle the cleanup and such of any variables. You could also set a 'cleanup' handler to 'unload' the module from the process when it is completed or even 'undef' specific variables. That way you can clear out the namespace and then other scripts calling the same named module but from a different path can actually load it. Of course all of this tends to go in the opposite direction from that in which mod_perl tries to go: the idea is to do as little processing as possible (particularly things like compiling modules) for each request. 73, Ged.
Re: mod_perl + UNIVERSAL
If the UNIVERSAL namespace is shared I would have thought one or the other (the last one?) would get the print_error sub and the other loses out but at some point they seem to coexist just fine. Whilst at some other point they as expected and one gets the others. Any theories? You have a bunch of different processes running. Some of them hit the forums first, and some hit the portal first. Last one wins. - Perrin
RE: mod_perl + UNIVERSAL
: ) As with any application that depends on the requirements. There really is no reason to cleanup the globals since they are still referenced and in memory. Perhaps you can consider an interface around your code which can handle the cleanup and such of any variables. You could also set a 'cleanup' handler to 'unload' the module from the process when it is completed or even 'undef' specific variables. That way you can clear out the namespace and then other scripts calling the same named module but from a different path can actually load it. Of course all of this tends to go in the opposite direction from that in which mod_perl tries to go: the idea is to do as little processing as possible (particularly things like compiling modules) for each request.
mod_perl + UNIVERSAL
Hi All, I have two mod_perl applications that run under different virtual servers on the same machine. I have named the modules within a directory for each so that they do not clash (e.g. application::master etc). However both applications make use of the UNIERVSAL package to create universally accessible methods (to return the current database handle for example) within the application. The thing is I am getting some weird behaviour where one application seems to be getting code from the other. In theory this isn't possible with the separated namespaces. I suspect my UNIERVSAL use is the problem. Can anyone verify this? Is it a known problem? Is there any way around it? Any help greatly appreciated. Matt.
