Re: [gsar@ActiveState.com: v5.6.1 trial2 is available]
On Tue, Mar 13, 2001 at 05:57:20PM -0800, Gurusamy Sarathy wrote: There is a change in behavior here that looks somewhat suspect because the comments didn't mention it. On Wed, Feb 21, 2001 at 09:32:04PM +0100, Jens-Uwe Mager wrote: +#ifdef USE_NATIVE_DLOPEN [...] +#else [...] +#ifndef RTLD_LAZY +# define RTLD_LAZY 0 +#endif +#ifndef RTLD_GLOBAL +# define RTLD_GLOBAL 0 +#endif [...] - RETVAL = dlopen(filename, 1) ; + RETVAL = dlopen(filename, RTLD_GLOBAL|RTLD_LAZY) ; It seems to me that dlopen() is now being called with a second argument of 0 instead of 1 if USE_NATIVE_DLOPEN wasn't set and those two constants aren't defined in the system headers. Is this an intentional change? Does it have potential to break anything on the pre-4.3 AIX versions? If you look in the source you will see that the mode argument of dlopen is not used at all in the dlopen emulation case, the argument "1" was not used in the previous version at all. And in fact in the dlopen emulator case there was no definition for the mode constants at all. I did change the arguments so the dlopen call can be used in both cases, with the emulator and with the native dlopen. -- Jens-Uwe Mager HELIOS Software GmbH Steinriede 3 30827 Garbsen Germany Phone: +49 5131 709320 FAX:+49 5131 709325 Internet: [EMAIL PROTECTED]
Re: cgi_to_mod_perl manpage suggestion
- Original Message - From: "Perrin Harkins" [EMAIL PROTECTED] To: "Andrew Ho" [EMAIL PROTECTED] Cc: "Issac Goldstand" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 4:56 AM Subject: Re: cgi_to_mod_perl manpage suggestion On Tue, 13 Mar 2001, Andrew Ho wrote: PHUm, you're getting me confused now, but PerlSendHeader On means that PHmod_perl WILL send headers. I still think that the above line is confusing: It is because mod_perl is not sending headers by itelf, but rather your script must provide the headers (to be returned by mod_perl). However, when you just say "mod_perl will send headers" it is misleading; it seems to indeicate that mod_perl will send "Content-Type: text/html\r\n\r\n" all by itself, and that conversely, to disable that PerlSendHeaders should be Off. I recognize this confusion. Most recovering CGI programmers think that "PerlSendHeader On" means that you no longer have to do this in your CGI: print "Content-type: text/html\n\n"; When in fact you still do. The manpage makes it sound like you don't. Perhaps a note to that effect would be helpful. I certainly want newbies to understand the docs, but the man page does say very explicitly "Just as with mod_cgi, PerlSendHeader will not send the MIME type and a terminating double newline. Your script must send that itself..." Those were the lines that finally caused me to even try it the other way. But although they are there, they took me a long time to comprehend after the previous (and even possibly subsequent) misunderstandings. Issac
Re: cgi_to_mod_perl manpage suggestion
At 03:34 PM 03/14/01 +0200, Issac Goldstand wrote: On Tue, 13 Mar 2001, Andrew Ho wrote: PHUm, you're getting me confused now, but PerlSendHeader On means that PHmod_perl WILL send headers. I still think that the above line is confusing: It is because mod_perl is not sending headers by itelf, but rather your script must provide the headers (to be returned by mod_perl). However, when you just say "mod_perl will send headers" it is misleading; it seems to indeicate that mod_perl will send "Content-Type: text/html\r\n\r\n" all by itself, and that conversely, to disable that PerlSendHeaders should be Off. Read it again. You are confusing "some" headers with "all" headers -- there's more than just Content-Type:. To me it doesn't sound at all like it will send content-type: PerlSendHeader On Now the response line and common headers will be sent as they are by mod_cgi. (response line and common headers != content type) And, just as with mod_cgi, PerlSendHeader will not send a terminating newline, your script must send that itself, e.g.: - print "Content-type: text/html\n\n"; All documentation has room for improvement, of course. It's confusing if you haven't written a mod_perl content handler before (or haven't read the perldoc Apache or the Eagle book) and don't know that you need $r-send_http_header under a normal content handler. And if you are like me, you have to read the docs a few times before it all makes sense. Also, note that Apache::Registry lets reasonably well written CGI scripts to run under both mod_cgi and Apache::Registry, which is what that man page is describing. It's not a CGI script if there's not a content-type: header sent. And the docs are not implying that you can turn on PerlSendHeader and then go through all your CGI scripts and remove the print "Content-type: text/html\n\n" lines. Bill Moseley mailto:[EMAIL PROTECTED]
Re: cgi_to_mod_perl manpage suggestion
- Original Message - From: "Bill Moseley" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 4:34 PM Subject: Re: cgi_to_mod_perl manpage suggestion At 03:34 PM 03/14/01 +0200, Issac Goldstand wrote: On Tue, 13 Mar 2001, Andrew Ho wrote: PHUm, you're getting me confused now, but PerlSendHeader On means that PHmod_perl WILL send headers. I still think that the above line is confusing: It is because mod_perl is not sending headers by itelf, but rather your script must provide the headers (to be returned by mod_perl). However, when you just say "mod_perl will send headers" it is misleading; it seems to indeicate that mod_perl will send "Content-Type: text/html\r\n\r\n" all by itself, and that conversely, to disable that PerlSendHeaders should be Off. Read it again. You are confusing "some" headers with "all" headers -- there's more than just Content-Type:. To me it doesn't sound at all like it will send content-type: PerlSendHeader On Now the response line and common headers will be sent as they are by mod_cgi. (response line and common headers != content type) And, just as with mod_cgi, PerlSendHeader will not send a terminating newline, your script must send that itself, e.g.: - print "Content-type: text/html\n\n"; All documentation has room for improvement, of course. It's confusing if you haven't written a mod_perl content handler before (or haven't read the perldoc Apache or the Eagle book) and don't know that you need $r-send_http_header under a normal content handler. And if you are like me, you have to read the docs a few times before it all makes sense. Also, note that Apache::Registry lets reasonably well written CGI scripts to run under both mod_cgi and Apache::Registry, which is what that man page is describing. It's not a CGI script if there's not a content-type: header sent. And the docs are not implying that you can turn on PerlSendHeader and then go through all your CGI scripts and remove the print "Content-type: text/html\n\n" lines. Bill Moseley mailto:[EMAIL PROTECTED] So basically, PerlSendHeaders On means that it will send information such as the return code (eg HTTP/1.1 200 OK) ETag, Date and other headers that Apache generally handles on its own under mod_cgi? If so, then I think that all that really needs to be done is instead of giving a small lecture on PerlSendHeader which will be confusing to newbies, why not just write something basically telling them to set it to On and not worry. Remember that this is just the porting manpage, and if people really want to make their own handlers then they'll eventually learn the ins and outs of PerlSendHeader.
Varaible scope memory under mod_perl
I have a module that I built on my own to handle
user authentication. At the moment, every perl script that I have calls a
method in this module using a cookie (Supplied by browser) as an argument.
Eventually I want to turn this into a mod_perl handler which instead of
returning the autherized user information (in a scalar called $uid) will add a
key to $ENV containing the authorized user id.
However, for the moment I have trouble in that the
$uid variables (or possibly the $cookie variables) are being remembered between
callings of the scripts. This results in unauthenticated users recieving
access t incorrect accounts. (Even authenticated users get other peoples
accounts occasionally).
In short, the module is called TFile::Authenticate,
and it has a "use" line in my mod_perl startup script, to maximize persistance
and minimize compile/load time. Additionally, each cgi script (for they
are still all scripts) "use"s the module.
Basically, the common authorization code in each
script looks something like this:
my $q=new CGI;my
$cookid=$q-cookie('sessionlid');if (!(defined($cookid))) {print
"Location: /login.html\r\n\r\n";exit;}my $uid=eval 'check_auth($cookid);';
#The above line calls the authentication script
which will return a valid $uid or undef if not validif (!(defined($uid)))
{print "Location: /login.html\r\n\r\n";exit;}my
$cookie=$q-cookie(-name="sessionlid",-value=$cookid,-expires=expdate_auth($cookid));
The scripts then proceed to do their work and when
they return content, contain the command
print STDOUT "Set-Cookie:
$cookie\r\n";
Now I _know_ that some of the variables are being
persistant, because when doing a telnet localhost 80, and requestinga
script,I actually got a responseincluding a cookie for a valid
authentication. Now, I'm still really not sure about
howthepersistance works, so I suppose I could just do something
like:
my $uid=undef;
my $cookid=undef;
my $cookie=undef;
...
If I include that at the beginning of all of the scripts, it could work,
but it seems to me to be a bit messy; I'm sure there's a better way.
Additionally, can anyone think of a better way toadd a handler to the
existing TFile::Authenticate module for mod_perl scripts, while leaving the
public interfaces open fornormal CGI (or any other) scripts?
Thanks,
Issac
Internet is a wonderful mechanism for making a fool
ofyourself in front of a very large audience.
--AnonymousMoving the mouse won't get you into trouble...
Clicking it might. --AnonymousPGP Key 0xE0FA561B -
Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA
561B
RE: Varaible scope memory under mod_perl
How could I
unsubscribe from [EMAIL PROTECTED]
Thank you so
much.
Steven.
-Original Message-From: Issac Goldstand
[mailto:[EMAIL PROTECTED]]Sent: Wednesday, March 14, 2001 9:00
AMTo: [EMAIL PROTECTED]Subject: Varaible scope
memory under mod_perl
I have a module that I built on my own to handle
user authentication. At the moment, every perl script that I have calls
a method in this module using a cookie (Supplied by browser) as an
argument. Eventually I want to turn this into a mod_perl handler which
instead of returning the autherized user information (in a scalar called $uid)
will add a key to $ENV containing the authorized user id.
However, for the moment I have trouble in that
the $uid variables (or possibly the $cookie variables) are being remembered
between callings of the scripts. This results in unauthenticated users
recieving access t incorrect accounts. (Even authenticated users get
other peoples accounts occasionally).
In short, the module is called
TFile::Authenticate, and it has a "use" line in my mod_perl startup script, to
maximize persistance and minimize compile/load time. Additionally, each
cgi script (for they are still all scripts) "use"s the module.
Basically, the common authorization code in each
script looks something like this:
my $q=new CGI;my
$cookid=$q-cookie('sessionlid');if (!(defined($cookid))) {print
"Location: /login.html\r\n\r\n";exit;}my $uid=eval 'check_auth($cookid);';
#The above line calls the authentication script
which will return a valid $uid or undef if not validif (!(defined($uid)))
{print "Location: /login.html\r\n\r\n";exit;}my
$cookie=$q-cookie(-name="sessionlid",-value=$cookid,-expires=expdate_auth($cookid));
The scripts then proceed to do their work and
when they return content, contain the command
print STDOUT "Set-Cookie:
$cookie\r\n";
Now I _know_ that some of the variables are being
persistant, because when doing a telnet localhost 80, and requestinga
script,I actually got a responseincluding a cookie for a valid
authentication. Now, I'm still really not sure about
howthepersistance works, so I suppose I could just do something
like:
my $uid=undef;
my $cookid=undef;
my $cookie=undef;
...
If I include that at the beginning of all of the scripts, it could work,
but it seems to me to be a bit messy; I'm sure there's a better way.
Additionally, can anyone think of a better way toadd a handler to
the existing TFile::Authenticate module for mod_perl scripts, while leaving
the public interfaces open fornormal CGI (or any other) scripts?
Thanks,
Issac
Internet is a wonderful mechanism for making a
fool ofyourself in front of a very large audience.
--AnonymousMoving the mouse won't get you into trouble...
Clicking it might. --AnonymousPGP Key 0xE0FA561B -
Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA
561B
Re: Varaible scope memory under mod_perl
agh! check the headers! Steven Zhu wrote: How could I unsubscribe from [EMAIL PROTECTED] you so much.Steven. -Original Message-
Re: cgi_to_mod_perl manpage suggestion
On Wed, 14 Mar 2001, Issac Goldstand wrote: So basically, PerlSendHeaders On means that it will send information such as the return code (eg HTTP/1.1 200 OK) ETag, Date and other headers that Apache generally handles on its own under mod_cgi? If so, then I think that all that really needs to be done is instead of giving a small lecture on PerlSendHeader which will be confusing to newbies, why not just write something basically telling them to set it to On and not worry. Remember that this is just the porting manpage, and if people really want to make their own handlers then they'll eventually learn the ins and outs of PerlSendHeader. This hopefully will give an indepth explanation of the behavior of this flag. May be too much :) http://thingy.kcilink.com/modperlguide/config/_Location_Configuration.html (scroll down to the PerlSendHeaders On part...) Notice, that the para says HTTP header, and it doesn't say anything about Content-type, which you always have to provide. Hmm, may be even that explanation can be improved. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
[OT] unsubscribing was Re: Varaible scope memory under mod_perl
I really don't see the point in putting list info in the headers. The people that have to ask these questions usually don't have full headers turned on. Why not put it at the bottom of each email instead of the headers like some other lists do? It would take up the same amount of space, and it would eliminate the 'how do I unsubscribe' and 'uuugh...see headers' emails. Brian B. ed phillips wrote: agh! check the headers! Steven Zhu wrote: How could I unsubscribe from [EMAIL PROTECTED] you so much.Steven. -Original Message-
unreleased sockets using DBI / DBD::mysql under mod_perl?
Hi, we are currently developing several Perl scripts for a big german site with high traffic and the need of fast DB connections. The webserver are Apache 1.3.14 setup with mod_perl (current version as far as I know). The scripts connect to a Mysql 3.2332 on another machine over a socket connections. Now the problem: High traffic result to many connections to the DB. The DB seems to be fast enough (4 Xeon 750 machine with 4 GB) to handle those requests. BUT after some time the DB get flooded by unauthorised connections. Looking at the DB server stats it doesn't look like a high demand for processor power... the machine is idling as far as a DB server can be idle. Those faulty connection, we can't get rid of. Once they are coming in, the DB doesn't seem capable of handling, authenticating or refusing them properly. We regard this as a some sort of mod_perl socket problems because performance tests during the night, using PHP with the same queries and similar load proof to be all correctly answered. No unauthenticated connection in the processlist of the mysql, even when there are 500 concurrent DB requests running. Taking a peek at the webserver netstats when connecting with Perl scripts show a lot of open and not closing socket connections to the mysql... only after some timeout period they get disconnected. Currently Perl tests over mod_cgi still have to be made, but I doubt this will be a problem, but who knows... maybe we have some DBD::mysql configuration problem here? This is surely the wrong list to ask... :-) but you'll never know, maybe sonmeone reading this can point me in the propper direction. Anyway, anyone experienced the same behaviour before? Any hint to a solution are greatly appreciated, we need a fix/solution/workaround soon! A word on Apache::DBI: Yes, we did try persistant connections to avoid heavy connection load on the mysql. BUT it simply didn't work. Well sort of. Persistant connections were established, but they never got reused. Until about 7 open connections resulted in a DB crash. Not nice. Same problem with a corresponding persistant connection test using PHP... maybe a Mysql client source configuration problem or something like it? Anyone experienced this before? Thanks for any help or hint, Jrn Janoschek. KLAHOLD - We make IT work! - http://www.klahold.de - WebDevelopment - http://www.klahold.de - Content-Management-System - http://www.interred.de
Re: unreleased sockets using DBI / DBD::mysql under mod_perl?
Joern Janoschek wrote: Hi, we are currently developing several Perl scripts for a big german site with high traffic and the need of fast DB connections. The webserver are Apache 1.3.14 setup with mod_perl (current version as far as I know). The scripts connect to a Mysql 3.2332 on another machine over a socket connections. Now the problem: High traffic result to many connections to the DB. The DB seems to be fast enough (4 Xeon 750 machine with 4 GB) to handle those requests. BUT after some time the DB get flooded by unauthorised connections. Looking at the DB server stats it doesn't look like a high demand for processor power... the machine is idling as far as a DB server can be idle. Those faulty connection, we can't get rid of. Once they are coming in, the DB doesn't seem capable of handling, authenticating or refusing them properly. We regard this as a some sort of mod_perl socket problems because performance tests during the night, using PHP with the same queries and similar load proof to be all correctly answered. No unauthenticated connection in the processlist of the mysql, even when there are 500 concurrent DB requests running. Taking a peek at the webserver netstats when connecting with Perl scripts show a lot of open and not closing socket connections to the mysql... only after some timeout period they get disconnected. Currently Perl tests over mod_cgi still have to be made, but I doubt this will be a problem, but who knows... maybe we have some DBD::mysql configuration problem here? This is surely the wrong list to ask... :-) but you'll never know, maybe sonmeone reading this can point me in the propper direction. Anyway, anyone experienced the same behaviour before? Any hint to a solution are greatly appreciated, we need a fix/solution/workaround soon! A word on Apache::DBI: Yes, we did try persistant connections to avoid heavy connection load on the mysql. BUT it simply didn't work. Well sort of. Persistant connections were established, but they never got reused. Until about 7 open connections resulted in a DB crash. Not nice. Same problem with a corresponding persistant connection test using PHP... maybe a Mysql client source configuration problem or something like it? Anyone experienced this before? There's no reason why Apache::DBI should not work - by the sounds of it the connections strings may have been different ? Apache::DBI works in an environment where on user ID is used to connect to the DB mulitple time. If you use two different connection strings Apache::DBI will try and make both persistent (IIRC). So check your DBI connection strings as they should be indentical. Greg Thanks for any help or hint, Jrn Janoschek. KLAHOLD - We make IT work! - http://www.klahold.de - WebDevelopment - http://www.klahold.de - Content-Management-System - http://www.interred.de
Re: unreleased sockets using DBI / DBD::mysql under mod_perl?
On Wed, 14 Mar 2001 18:46:31 +, Greg Cope wrote: There's no reason why Apache::DBI should not work - by the sounds of it the connections strings may have been different ? Apache::DBI works in an environment where on user ID is used to connect to the DB mulitple time. If you use two different connection strings Apache::DBI will try and make both persistent (IIRC). So check your DBI connection strings as they should be indentical. Here is the problem: The connection strings _are_ the same. No change at all between two connects... same host, same user, same DB, even the same table (not that it bothers)... nothing changes. That's the strange thing and that's what we didn't understand at all and what pushed us to the point where we disabled Apache::DBI. Could it be that there is a connection between the socket problem and the ever rising persistent connections? Maybe the Apache::DBI cannot share an already connected handle because the system says the socket is still in use and not free at all. That would explain the unusual behaviour of Apache::DBI... Maybe someone who hasn't an explaination could tell me at least where to look at? Linux system? Apache? mod_perl? Mysql? DBI/DBD? Thanks anyway, Jrn Janoschek. KLAHOLD - We make IT work! - http://www.klahold.de - WebDevelopment - http://www.klahold.de - Content-Management-System - http://www.interred.de
Re: cgi_to_mod_perl manpage suggestion
On Wed, 14 Mar 2001, Issac Goldstand wrote: I still think that the above line is confusing: It is because mod_perl is not sending headers by itelf, but rather your script must provide the headers (to be returned by mod_perl). However, when you just say "mod_perl will send headers" it is misleading; it seems to indeicate that mod_perl will send "Content-Type: text/html\r\n\r\n" all by itself, and that conversely, to disable that PerlSendHeaders should be Off. Would it help if it said "PerlSendHeader On makes mod_perl act just like CGI with regard to headers"? - Perrin
RE: [OT] unsubscribing was Re: Varaible scope memory under mod_perl
First of All, I would like to thank you all for quick responses. This is my situation. I originally joined this list as another user (having different user email account). Now I got those emails from the alias of my original account. If I just send mail to [EMAIL PROTECTED], I believe that it does not help because I never joined the list as my current email. How could I unsubscribe my original account by my current email. Is there any way I could put my original email in the body or somewhere. Thanks again -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of B. Burke Sent: Wednesday, March 14, 2001 10:21 AM To: [EMAIL PROTECTED] Subject: [OT] unsubscribing was Re: Varaible scope memory under mod_perl I really don't see the point in putting list info in the headers. The people that have to ask these questions usually don't have full headers turned on. Why not put it at the bottom of each email instead of the headers like some other lists do? It would take up the same amount of space, and it would eliminate the 'how do I unsubscribe' and 'uuugh...see headers' emails. Brian B. ed phillips wrote: agh! check the headers! Steven Zhu wrote: How could I unsubscribe from [EMAIL PROTECTED] you so much.Steven. -Original Message-
Re: [OT] Client Certificate Authentification module?
"KV" == Kees Vonk [EMAIL PROTECTED] writes: KV I am looking for a module that will allow me to use Client KV Certificates to authenticate the users. I am pretty sure I have KV come accros this before, but I cannot find it anywhere. Anybody KV know where I can find this. This is an apache / mod_ssl configuration issue: http://www.modssl.org/docs/2.8/ssl_howto.html#ToC6 I'm not aware of any mod_perl API into the SSL stuff. I've got live configuration of a setup that uses this stuff, so mail me if you get stuck ... - Adam
Apache::ASP problems
Hello, Would anybody be able to help with this problem? I am using Apache, mod_perl and Apache::ASP.When I call an asp file from the browser it seems to read the file content as html, eg on a form, in the input area it shows the name of the variable, it dosen't recognise the perlScript and just prints it as text. You don't know what might be causing this problem ? Is this a configuration error. Thanks, Leighton
Apache::StatINC patch
Hi,
While developing with mod_perl and Apache::ASP here at Aduva SID
department, we've came across an annoying problem.
Apache::ASP adds it's 'Global' directory to @INC. We naturally
used it to store modules. Since mod_perl resets @INC across requests
but doesn't reset %INC, Apache::StatINC sometimes found changes in the
used modules, but couldn't reload them (since their directory wasn't in
@INC).
This patch will insert missing directories into @INC on the fly.
--
Best regards,
Ilya Konstantinov
--- StatINC.pm.old Tue Mar 13 18:30:57 2001
+++ StatINC.pm Tue Mar 13 17:30:08 2001
@@ -11,7 +11,7 @@
$r-dir_config("UndefOnReload")) || '') eq "on");
my $DEBUG = ref($r) (lc($r-dir_config("StatINCDebug") || '') eq "on");
$DEBUG = $r-dir_config("StatINC_Debug") if ref($r)
$r-dir_config("StatINC_Debug");
-
+
while(my($key,$file) = each %INC) {
local $^W = 0;
my $mtime = (stat $file)[9];
@@ -20,16 +20,38 @@
unless(defined $Stat{$file}) {
$Stat{$file} = $^T;
}
+# if modified, reload the module
if($mtime $Stat{$file}) {
+ # make sure file's prefix is in @INC
+ my $found_in_inc;
+ for (@INC) {
+ if(index($file,$_) == 0) {
+ $found_in_inc = 1;
+ last;
+ }
+ }
+
+if(!$found_in_inc) {
+ my $inc_dir = substr($file, 0, length($file)-length($key)-1);
+ push @INC, $inc_dir;
+ warn "Apache::StatINC: process $$ adding $inc_dir to \@INC\n"
+ if $DEBUG 0;
+}
+
if($do_undef and $key =~ /\.pm$/) {
require Apache::Symbol;
my $class = Apache::Symbol::file2class($key);
$class-Apache::Symbol::undef_functions( undef, 1 );
}
delete $INC{$key};
- require $key;
- warn "Apache::StatINC: process $$ reloading $key\n"
- if $DEBUG 0;
+ eval{ require $key };
+ if ($@) {
+ warn "Apache::StatINC: process $$ failed to reload $key. $@"
+ if $DEBUG 0;
+ } else {
+ warn "Apache::StatINC: process $$ reloading $key.\n"
+ if $DEBUG 0;
+}
}
$Stat{$file} = $mtime;
}
Re: cgi_to_mod_perl manpage suggestion
Possibly. I think the idea is to keep in mind that people who are reading cgi_to_mod_perl are total newbies. Not only that, but many are planning on staying total newbies forever; they don't care about what mod_perl is actually for (or actually can do). I think that the cgi_to_mod_perl manpage should be targeted at that kind of perspective... Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B - Original Message - From: "Perrin Harkins" [EMAIL PROTECTED] To: "Issac Goldstand" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 9:30 PM Subject: Re: cgi_to_mod_perl manpage suggestion On Wed, 14 Mar 2001, Issac Goldstand wrote: I still think that the above line is confusing: It is because mod_perl is not sending headers by itelf, but rather your script must provide the headers (to be returned by mod_perl). However, when you just say "mod_perl will send headers" it is misleading; it seems to indeicate that mod_perl will send "Content-Type: text/html\r\n\r\n" all by itself, and that conversely, to disable that PerlSendHeaders should be Off. Would it help if it said "PerlSendHeader On makes mod_perl act just like CGI with regard to headers"? - Perrin
Re: $r and Registry(NG)* scripts
Stas Bekman wrote:
On Tue, 13 Mar 2001, Daniel wrote:
All scripts on
site start with:
use vars qw(%input $r);
$r = Apache-request;
This has worked fine...no complaints in log files...until I switched the
handler from Registry to RegistryNG;
Now I see occasional:
Variable "$r" will not stay shared at /home/httpd/perl/daily-news.pl
line 9 (#1)
in log files.
http://perl.apache.org/guide/troubleshooting.html#Value_of_x_will_not_stay_shared
Thanks for the reply and the guide (of which I'm pretty familiar) Stas.
See comments above and below. $r is global in my scripts.
Unless I'm misunderstanding something, the warning shouldn't be
occurring. Wasn't under Registry. Also these warnings do not appear on
every page request, so I'm wondering if it has something to do with the
compile stage of perlrun and/or something that happens during a new
apache process creation.
Sorry, I've jumped too fast with a conclusion at seeing the standard
"...will not stay shared".
lol...np...you're doing a great job for mod_perl helping newcomers.
But in order to debug the problem, I have to be
able to reproduce it. Are you saying that the script below, as it is,
has this problem? But it's not the whole script, I understand. Can you
write a small reproducing test?
I tried last nite to put something together to trigger the error
everytime. All I came up with was reducing maxrequestsperchild to 10
and some scary lwp selfdownloading, $self-lookup($self_uri)-run code.
The code did not produce the exact error but managed to produce:
Can't locate object method "log_error" via package "Apache::RegistryNG"
at /usr/lib/perl5/site_perl/5.005/i386-linux/Apache/PerlRun.pm line 53.
Apache::PerlRun::can_compile('Apache::RegistryNG=HASH(0x876a8dc)')
called at /usr/lib/perl5/site_perl/5.005/i386-linux/Apache/RegistryNG.pm
line 33
Apache::RegistryNG::handler('Apache=SCALAR(0x876af3c)') called
at /dev/null line 0
eval {...} called at /dev/null line 0
I can't post the full site code either.
Best I can do is expand the description and other oddities I've noticed
here on site.
There's about six heavily used RegistryNG scripts onsite.
Each calls a php header via $subr-run which does a virtual() to include
a RegistryNG banner ad.
Each calls a php footer via $subr-run which does a virtual() to include
about five other RegistryNG banners ads and a virtual() for a RegistryNG
list of the day's stories.
Oddity: after any $subr-run calls, the next print() may or may not
work. I have to print "!--anything--"; to use print() reliably after a
$subr-run call.
Oddity: I use $ENV{SCRIPT_NAME} for scripts that call themselves. Once a
$subr-run has occurred $ENV{SCRIPT_NAME} $ENV{SCRIPT_FILENAME} are
changed in the caller to the values of the $subr %ENV (does it not try
to restore?).
Lemme know if any of this sounds familiar.
Error occurs at first $r assignment:
first nine from daily-news.pl:
#!/usr/bin/perl -w
use strict;
use DBI;
use date_site;
my $dateformat = date_site::dateformat;
use Apache::Request;
use vars qw($dbh %input %output %filebase $r %sites); #vars used on $r
$r = Apache-request; #--error first happens here
--
Daniel Bohling
NewsFactor Network
Very[OT]:Technical query re: scratchpad lookups for my() vars
Anybody know offhand *why* my() lexicals are supposedly faster? If they're stored on a scratchpad for the scope, which is an array, (technically a stack of them to accommodate recursion,) then exactly how does Perl go about finding which data location you mean when you say $x for a lexical? $::x has to go through the package lookup, which (if I recall correctly) is technically a hash element of a hash element at least..but if the scratchpad has a lot of scope-specific lexicals, how does it find which one is x? my $brain = 'tapioca'; #=o) __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/
Re: [OT] unsubscribing was Re: Varaible scope memory under mod_perl
[EMAIL PROTECTED] wrote: I really don't see the point in putting list info in the headers. The people that have to ask these questions usually don't have full headers turned on. Why not put it at the bottom of each email instead of the headers like some other lists do? It would take up the same amount of space, and it would eliminate the 'how do I unsubscribe' and 'uuugh...see headers' emails. Well actually, it doesn't eliminate those messages. It does make them more amusing, however.
Re: unreleased sockets using DBI / DBD::mysql under mod_perl?
Joern Janoschek wrote: On Wed, 14 Mar 2001 18:46:31 +, Greg Cope wrote: There's no reason why Apache::DBI should not work - by the sounds of it the connections strings may have been different ? Apache::DBI works in an environment where on user ID is used to connect to the DB mulitple time. If you use two different connection strings Apache::DBI will try and make both persistent (IIRC). So check your DBI connection strings as they should be indentical. Here is the problem: The connection strings _are_ the same. No change at all between two connects... same host, same user, same DB, even the same table (not that it bothers)... nothing changes. That's the strange thing and that's what we didn't understand at all and what pushed us to the point where we disabled Apache::DBI. Could it be that there is a connection between the socket problem and the ever rising persistent connections? Maybe the Apache::DBI cannot share an already connected handle because the system says the socket is still in use and not free at all. That would explain the unusual behaviour of Apache::DBI... Maybe someone who hasn't an explaination could tell me at least where to look at? Linux system? Apache? mod_perl? Mysql? DBI/DBD? This would appear to be a DBI problem - but I'm no expert. Have you tried the DBI list ? I am afraid I can shed no further light on this. Greg Thanks anyway, Jrn Janoschek. KLAHOLD - We make IT work! - http://www.klahold.de - WebDevelopment - http://www.klahold.de - Content-Management-System - http://www.interred.de
Re: Very[OT]:Technical query re: scratchpad lookups for my() vars
--- Robert Landrum [EMAIL PROTECTED] wrote:
I could be wrong, but as I recall, when your program enters a scope,
perl immediatly identifies the the scratchpad to use. Then, it need
only search backwards up the tree of scratchpads to find the variable
"$x", which is faster than iterating through the STHASH looking for a
localized or global $x.
But how does it locate x in the scratchpad? Where're the docs?
Or am I gonna have to read the code? =lol!
I think Mark-Jason Dominus has much more indepth look at the perl
internals on his website... plover.com
Great articles, read them today.
Learned a new trick:
my $fh = do { local *FH; };
But nothing about the structural/algorithmic mechanics. :
__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
Re: Apache::ASP problems
Leighton Donal Jones wrote: Hello, Would anybody be able to help with this problem? I am using Apache, mod_perl and Apache::ASP.When I call an asp file from the browser it seems to read the file content as html, eg on a form, in the input area it shows the name of the variable, it dosen't recognise the perlScript and just prints it as text. You don't know what might be causing this problem ? Is this a configuration error. Your Apache::ASP config is likely not being picked up, so the ASP script is being rendered as straight HTML. Make sure you can get the ./site/eg examples that come with the Apache::ASP distribution working. Once done with that, you can likely leverage your configuration know-how into real development and production configs. The examples in particular need to have their .htaccess activated, see http://www.apache-asp.org/install.html#Quick%20Start Make sure you also understand what the various config options do for you once you get ASP working. If you don't need it, don't use it! See: http://www.apache-asp.org/config.html --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: Very[OT]:Technical query re: scratchpad lookups for my() vars
At 03:52 PM 3/14/01 -0800, Paul wrote: But nothing about the structural/algorithmic mechanics. : From the perlsub docs: Variables declared with my are not part of any package and are therefore never fully qualified with the package name. In particular, you're not allowed to try to make a package variable (or other global) lexical: my $pack::var; # ERROR! Illegal syntax my $_; # also illegal (currently) In fact, a dynamic variable (also known as package or global variables) are still accessible using the fully qualified :: notation even while a lexical of the same name is also visible: package main; local $x = 10; my$x = 20; print "$x and $::x\n"; That will print out 20 and 10. There is _no_ stash of lexicals during execution, only during compilation. I guess one of the reasons lexicals are faster. Elizabeth Mattijsen
Re: Very[OT]:Technical query re: scratchpad lookups for my() vars
--- Elizabeth Mattijsen [EMAIL PROTECTED] wrote: At 03:52 PM 3/14/01 -0800, Paul wrote: But nothing about the structural/algorithmic mechanics. : From the perlsub docs: Variables declared with my are not part of any package and are therefore never fully qualified with the package name. In particular, you're not allowed to try to make a package variable (or other global) lexical: my $pack::var; # ERROR! Illegal syntax my $_; # also illegal (currently) In fact, a dynamic variable (also known as package or global variables) are still accessible using the fully qualified :: notation even while a lexical of the same name is also visible: package main; local $x = 10; my$x = 20; print "$x and $::x\n"; That will print out 20 and 10. There is _no_ stash of lexicals during execution, only during compilation. I guess one of the reasons lexicals are faster. Elizabeth Mattijsen An excellent example, all known and understood. What I can't find is this: I know that my($x) puts x on this scope's scratchpad (and not in any package space), but rather than a hash named main:: with a key named x (which is, as I understand it, an oversimplification perhaps, but basically what Perl does internally for $main::x), exactly *how* does Perl "put" x into the scratchpad AV*? and once it's there, what did it store? How does it know that entry is 'x'? is it just a reference to the actual value? None of this is critical for anything I'm doing right now, but I'm a detail hound. I want to *understand* it, so that in the future I can make intelligent decisions about what would be a "better" way to write any given algorithm, without just relying on popular wisdom and "urban legend". =o) (That's why I said it was Very[OT], lol) Paul __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/
Re: cgi_to_mod_perl manpage suggestion
On Wed, 14 Mar 2001, Perrin Harkins wrote: On Wed, 14 Mar 2001, Issac Goldstand wrote: I still think that the above line is confusing: It is because mod_perl is not sending headers by itelf, but rather your script must provide the headers (to be returned by mod_perl). However, when you just say "mod_perl will send headers" it is misleading; it seems to indeicate that mod_perl will send "Content-Type: text/html\r\n\r\n" all by itself, and that conversely, to disable that PerlSendHeaders should be Off. Would it help if it said "PerlSendHeader On makes mod_perl act just like CGI with regard to headers"? A small correction: "PerlSendHeader On makes mod_perl act just like mod_cgi with regard to HTTP headers" :) CGI is a protocol... _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cgi_to_mod_perl manpage suggestion
Hello, SBA small correction: "PerlSendHeader On makes mod_perl act just like SBmod_cgi with regard to HTTP headers" :) +1 vote for adding this simple sentence, which IMO would clear up lots of CGI to mod_perl beginner confusion. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: cgi_to_mod_perl manpage suggestion
Personally I'll admit that I've gotten screwed by this before... I usually remember that it's a setting and set it one way, and then when my script doesnt work, I set it the other way. Of course I didnt read the docs thoroughly, but because it was confusing, I just try it until it worked. Maybe other people aren't as patient. I would be all for the clear explanation. At 08:28 PM 3/14/2001 -0800, Andrew Ho wrote: Hello, SBA small correction: "PerlSendHeader On makes mod_perl act just like SBmod_cgi with regard to HTTP headers" :) +1 vote for adding this simple sentence, which IMO would clear up lots of CGI to mod_perl beginner confusion. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 -- __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
Installing mod_perl on MacOSX
Hello, has anyone ever installed/compiled mod_perl for MacOSX? If so, how exactly did you do it? Many thanks. Philippe de Rochambeau
cvs commit: modperl-2.0/src/modules/perl mod_perl.c modperl_config.c modperl_config.h modperl_interp.c modperl_types.h
dougm 01/03/14 00:22:51
Modified:src/modules/perl mod_perl.c modperl_config.c
modperl_config.h modperl_interp.c modperl_types.h
Log:
allow PerlInterpLifetime to be per-dir for subrequest and request lifetime
Revision ChangesPath
1.32 +3 -3 modperl-2.0/src/modules/perl/mod_perl.c
Index: mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- mod_perl.c2001/03/14 05:22:49 1.31
+++ mod_perl.c2001/03/14 08:22:47 1.32
@@ -129,7 +129,7 @@
char *name = modperl_server_desc(s, p);
MP_TRACE_i(MP_FUNC, "PerlInterpLifetime set to %s for %s\n",
- modperl_interp_lifetime_desc(scfg), name);
+ modperl_interp_lifetime_desc(scfg-interp_lifetime), name);
#endif /* MP_TRACE */
if (scfg-mip-tipool-idle) {
@@ -220,8 +220,8 @@
"Min number of spare Perl interpreters"),
MP_SRV_CMD_TAKE1("PerlInterpMaxRequests", interp_max_requests,
"Max number of requests per Perl interpreters"),
-MP_SRV_CMD_TAKE1("PerlInterpLifetime", interp_lifetime,
- "Lifetime of a Perl interpreter (connection or request)"),
+MP_DIR_CMD_TAKE1("PerlInterpLifetime", interp_lifetime,
+ "Lifetime of a Perl interpreter"),
#endif
MP_CMD_ENTRIES,
{ NULL },
1.20 +32 -7 modperl-2.0/src/modules/perl/modperl_config.c
Index: modperl_config.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_config.c,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- modperl_config.c 2001/03/14 05:22:49 1.19
+++ modperl_config.c 2001/03/14 08:22:48 1.20
@@ -21,6 +21,12 @@
void *modperl_create_dir_config(apr_pool_t *p, char *dir)
{
modperl_dir_config_t *dcfg = modperl_dir_config_new(p);
+
+#ifdef USE_ITHREADS
+/* defaults to per-server lifetime */
+dcfg-interp_lifetime = MP_INTERP_LIFETIME_UNDEF;
+#endif
+
return dcfg;
}
@@ -226,31 +232,50 @@
#ifdef USE_ITHREADS
static const char *MP_interp_lifetime_desc[] = {
-"none", "request", "connection",
+"undef", "subrequest", "request", "connection",
};
-const char *modperl_interp_lifetime_desc(modperl_srv_config_t *scfg)
+const char *modperl_interp_lifetime_desc(modperl_interp_lifetime_e lifetime)
{
-return MP_interp_lifetime_desc[scfg-interp_lifetime];
+return MP_interp_lifetime_desc[lifetime];
}
+#define MP_INTERP_LIFETIME_OPTS "PerlInterpLifetime must be one of "
+
+#define MP_INTERP_LIFETIME_DIR_OPTS \
+MP_INTERP_LIFETIME_OPTS "subrequest or request"
+
+#define MP_INTERP_LIFETIME_SRV_OPTS \
+MP_INTERP_LIFETIME_OPTS "subrequest, request or connection"
+
MP_DECLARE_SRV_CMD(interp_lifetime)
{
+modperl_interp_lifetime_e *lifetime;
+modperl_dir_config_t *dcfg = (modperl_dir_config_t *)dummy;
MP_dSCFG(parms-server);
+int is_per_dir = parms-path ? 1 : 0;
+
+lifetime = is_per_dir ? dcfg-interp_lifetime : scfg-interp_lifetime;
switch (toLOWER(*arg)) {
+ case 's':
+if (strcaseEQ(arg, "subrequest")) {
+*lifetime = MP_INTERP_LIFETIME_SUBREQUEST;
+break;
+}
case 'r':
if (strcaseEQ(arg, "request")) {
-scfg-interp_lifetime = MP_INTERP_LIFETIME_REQUEST;
+*lifetime = MP_INTERP_LIFETIME_REQUEST;
break;
}
case 'c':
-if (strcaseEQ(arg, "connection")) {
-scfg-interp_lifetime = MP_INTERP_LIFETIME_CONNECTION;
+if (!is_per_dir strcaseEQ(arg, "connection")) {
+*lifetime = MP_INTERP_LIFETIME_CONNECTION;
break;
}
default:
-return "PerlInterpLifetime must be one of connection or request";
+return is_per_dir ?
+MP_INTERP_LIFETIME_DIR_OPTS : MP_INTERP_LIFETIME_SRV_OPTS;
};
return NULL;
1.19 +13 -3 modperl-2.0/src/modules/perl/modperl_config.h
Index: modperl_config.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_config.h,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- modperl_config.h 2001/03/14 05:22:49 1.18
+++ modperl_config.h 2001/03/14 08:22:48 1.19
@@ -35,14 +35,20 @@
MP_DECLARE_SRV_CMD(interp_max_requests);
MP_DECLARE_SRV_CMD(interp_lifetime);
-const char *modperl_interp_lifetime_desc(modperl_srv_config_t *scfg);
+const char
cvs commit: modperl-2.0/src/modules/perl modperl_callback.c modperl_callback.h
dougm 01/03/14 09:28:07
Modified:src/modules/perl modperl_callback.c modperl_callback.h
Log:
canonicalize MP_HANDLER_TYPE_ names
Revision ChangesPath
1.26 +17 -15modperl-2.0/src/modules/perl/modperl_callback.c
Index: modperl_callback.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_callback.c,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- modperl_callback.c2001/03/14 05:22:49 1.25
+++ modperl_callback.c2001/03/14 17:28:07 1.26
@@ -173,23 +173,23 @@
}
switch (type) {
- case MP_HANDLER_TYPE_DIR:
+ case MP_HANDLER_TYPE_PER_DIR:
av = dcfg-handlers[idx];
MP_TRACE_a_do(desc = modperl_per_dir_handler_desc(idx));
break;
- case MP_HANDLER_TYPE_SRV:
+ case MP_HANDLER_TYPE_PER_SRV:
av = scfg-handlers[idx];
MP_TRACE_a_do(desc = modperl_per_srv_handler_desc(idx));
break;
- case MP_HANDLER_TYPE_CONN:
+ case MP_HANDLER_TYPE_CONNECTION:
av = scfg-connection_cfg-handlers[idx];
MP_TRACE_a_do(desc = modperl_connection_handler_desc(idx));
break;
- case MP_HANDLER_TYPE_FILE:
+ case MP_HANDLER_TYPE_FILES:
av = scfg-files_cfg-handlers[idx];
MP_TRACE_a_do(desc = modperl_files_handler_desc(idx));
break;
- case MP_HANDLER_TYPE_PROC:
+ case MP_HANDLER_TYPE_PROCESS:
av = scfg-process_cfg-handlers[idx];
MP_TRACE_a_do(desc = modperl_process_handler_desc(idx));
break;
@@ -222,16 +222,16 @@
handlers = (modperl_handler_t **)av-elts;
switch (type) {
- case MP_HANDLER_TYPE_DIR:
- case MP_HANDLER_TYPE_SRV:
+ case MP_HANDLER_TYPE_PER_DIR:
+ case MP_HANDLER_TYPE_PER_SRV:
modperl_handler_make_args(aTHX_ av_args,
"Apache::RequestRec", r, NULL);
break;
- case MP_HANDLER_TYPE_CONN:
+ case MP_HANDLER_TYPE_CONNECTION:
modperl_handler_make_args(aTHX_ av_args,
"Apache::Connection", c, NULL);
break;
- case MP_HANDLER_TYPE_FILE:
+ case MP_HANDLER_TYPE_FILES:
{
apr_pool_t *pconf, *plog, *ptemp;
@@ -248,7 +248,7 @@
"Apache::Server", s, NULL);
}
break;
- case MP_HANDLER_TYPE_PROC:
+ case MP_HANDLER_TYPE_PROCESS:
{
apr_pool_t *pconf;
@@ -292,29 +292,31 @@
int modperl_per_dir_callback(int idx, request_rec *r)
{
-return modperl_run_handlers(idx, r, NULL, r-server, MP_HANDLER_TYPE_DIR);
+return modperl_run_handlers(idx, r, NULL, r-server,
+MP_HANDLER_TYPE_PER_DIR);
}
int modperl_per_srv_callback(int idx, request_rec *r)
{
-return modperl_run_handlers(idx, r, NULL, r-server, MP_HANDLER_TYPE_SRV);
+return modperl_run_handlers(idx, r, NULL, r-server,
+MP_HANDLER_TYPE_PER_SRV);
}
int modperl_connection_callback(int idx, conn_rec *c)
{
return modperl_run_handlers(idx, NULL, c, c-base_server,
-MP_HANDLER_TYPE_CONN);
+MP_HANDLER_TYPE_CONNECTION);
}
void modperl_process_callback(int idx, apr_pool_t *p, server_rec *s)
{
-modperl_run_handlers(idx, NULL, NULL, s, MP_HANDLER_TYPE_PROC, p);
+modperl_run_handlers(idx, NULL, NULL, s, MP_HANDLER_TYPE_PROCESS, p);
}
void modperl_files_callback(int idx,
apr_pool_t *pconf, apr_pool_t *plog,
apr_pool_t *ptemp, server_rec *s)
{
-modperl_run_handlers(idx, NULL, NULL, s, MP_HANDLER_TYPE_FILE,
+modperl_run_handlers(idx, NULL, NULL, s, MP_HANDLER_TYPE_FILES,
pconf, plog, ptemp);
}
1.13 +5 -5 modperl-2.0/src/modules/perl/modperl_callback.h
Index: modperl_callback.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_callback.h,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- modperl_callback.h2001/03/14 00:37:52 1.12
+++ modperl_callback.h2001/03/14 17:28:07 1.13
@@ -10,11 +10,11 @@
#define ap_hook_fixup ap_hook_fixups
#define ap_hook_logap_hook_log_transaction
-#define MP_HANDLER_TYPE_DIR 1
-#define MP_HANDLER_TYPE_SRV 2
-#define MP_HANDLER_TYPE_CONN 3
-#define MP_HANDLER_TYPE_PROC 4
-#define MP_HANDLER_TYPE_FILE 5
+#define MP_HANDLER_TYPE_PER_DIR1
+#define MP_HANDLER_TYPE_PER_SRV2
+#define
cvs commit: modperl-2.0/src/modules/perl modperl_mgv.c modperl_perl_includes.h
dougm 01/03/14 17:26:18
Modified:src/modules/perl modperl_mgv.c modperl_perl_includes.h
Log:
fixes to compile with non-ithreads 5.6.0 Perl
Revision ChangesPath
1.2 +3 -1 modperl-2.0/src/modules/perl/modperl_mgv.c
Index: modperl_mgv.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_mgv.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- modperl_mgv.c 2001/03/09 23:42:04 1.1
+++ modperl_mgv.c 2001/03/15 01:26:18 1.2
@@ -205,7 +205,7 @@
else {
if ((cv = get_cv(name, FALSE))) {
handler-mgv_cv =
-modperl_mgv_compile(aTHX, p, HvNAME(GvSTASH(CvGV(cv;
+modperl_mgv_compile(aTHX_ p, HvNAME(GvSTASH(CvGV(cv;
modperl_mgv_append(aTHX_ p, handler-mgv_cv, GvNAME(CvGV(cv)));
MpHandlerPARSED_On(handler);
return 1;
@@ -312,8 +312,10 @@
static int modperl_dw_hash_handlers(apr_pool_t *p, server_rec *s,
void *cfg, char *d, void *data)
{
+#ifdef USE_ITHREADS
MP_dSCFG(s);
MP_dSCFG_dTHX;
+#endif
int i;
modperl_dir_config_t *dir_cfg = (modperl_dir_config_t *)cfg;
1.4 +4 -0 modperl-2.0/src/modules/perl/modperl_perl_includes.h
Index: modperl_perl_includes.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_perl_includes.h,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- modperl_perl_includes.h 2001/01/21 18:19:56 1.3
+++ modperl_perl_includes.h 2001/03/15 01:26:18 1.4
@@ -39,4 +39,8 @@
#undef dNOOP
#define dNOOP extern int __attribute__ ((unused)) Perl___notused
+#ifndef G_METHOD
+# define G_METHOD 64
+#endif
+
#endif /* MODPERL_PERL_INCLUDES_H */
cvs commit: modperl-2.0/src/modules/perl mod_perl.c modperl_gtop.c modperl_gtop.h
dougm 01/03/14 17:55:44
Modified:src/modules/perl mod_perl.c modperl_gtop.c modperl_gtop.h
Log:
fixes to compile without MP_TRACE
Revision ChangesPath
1.34 +2 -0 modperl-2.0/src/modules/perl/mod_perl.c
Index: mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- mod_perl.c2001/03/15 01:47:00 1.33
+++ mod_perl.c2001/03/15 01:55:44 1.34
@@ -151,6 +151,8 @@
MP_TRACE_i(MP_FUNC, "PerlInterpLifetime set to %s for %s\n",
modperl_interp_lifetime_desc(scfg-interp_lifetime), name);
+#else
+char *name = NULL;
#endif /* MP_TRACE */
if (scfg-mip-tipool-idle) {
1.7 +2 -2 modperl-2.0/src/modules/perl/modperl_gtop.c
Index: modperl_gtop.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_gtop.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- modperl_gtop.c2001/03/04 18:49:38 1.6
+++ modperl_gtop.c2001/03/15 01:55:44 1.7
@@ -1,6 +1,6 @@
-#ifdef MP_USE_GTOP
-
#include "mod_perl.h"
+
+#ifdef MP_USE_GTOP
static int modperl_gtop_size_string(size_t size, char *size_string)
{
1.3 +4 -0 modperl-2.0/src/modules/perl/modperl_gtop.h
Index: modperl_gtop.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_gtop.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- modperl_gtop.h2000/08/14 03:10:45 1.2
+++ modperl_gtop.h2001/03/15 01:55:44 1.3
@@ -1,6 +1,10 @@
#ifndef MODPERL_GTOP_H
#define MODPERL_GTOP_H
+#ifndef MP_TRACE
+#undef MP_USE_GTOP
+#endif
+
#ifdef MP_USE_GTOP
#include glibtop.h
cvs commit: modperl-2.0/src/modules/perl mod_perl.c modperl_interp.c
dougm 01/03/14 20:34:04
Modified:src/modules/perl mod_perl.c modperl_interp.c
Log:
need to PERL_SET_CONTEXT to parent perl in non-threaded mpms
give a little more trace info about interpreters in virtual hosts
Revision ChangesPath
1.36 +3 -2 modperl-2.0/src/modules/perl/mod_perl.c
Index: mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- mod_perl.c2001/03/15 02:17:35 1.35
+++ mod_perl.c2001/03/15 04:34:04 1.36
@@ -98,8 +98,9 @@
/* if alloc flags is On, virtual host gets its own parent perl */
if (MpSrvPARENT(scfg)) {
perl = modperl_startup(s, p);
-MP_TRACE_i(MP_FUNC, "modperl_startup() server=%s\n",
- s-server_hostname);
+MP_TRACE_i(MP_FUNC,
+ "created parent interpreter for VirtualHost %s\n",
+ modperl_server_desc(s, p));
}
#ifdef USE_ITHREADS
1.24 +6 -2 modperl-2.0/src/modules/perl/modperl_interp.c
Index: modperl_interp.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_interp.c,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- modperl_interp.c 2001/03/15 02:17:35 1.23
+++ modperl_interp.c 2001/03/15 04:34:04 1.24
@@ -215,8 +215,12 @@
modperl_interp_lifetime_e lifetime;
if (!scfg-threaded_mpm) {
-MP_TRACE_i(MP_FUNC, "using parent 0x%lx for non-threaded mpm\n",
- (unsigned long)scfg-mip-parent);
+MP_TRACE_i(MP_FUNC,
+ "using parent 0x%lx for non-threaded mpm (%s:%d)\n",
+ (unsigned long)scfg-mip-parent,
+ s-server_hostname, s-port);
+/* XXX: if no VirtualHosts w/ PerlOptions +Parent we can skip this */
+PERL_SET_CONTEXT(scfg-mip-parent-perl);
return scfg-mip-parent;
}
cvs commit: modperl-2.0/src/modules/perl modperl_callback.c modperl_config.c modperl_config.h modperl_interp.c modperl_types.h
dougm 01/03/14 23:04:41
Modified:src/modules/perl modperl_callback.c modperl_config.c
modperl_config.h modperl_interp.c modperl_types.h
Log:
support "PerlInterpLifetime handler"
Revision ChangesPath
1.29 +3 -5 modperl-2.0/src/modules/perl/modperl_callback.c
Index: modperl_callback.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_callback.c,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- modperl_callback.c2001/03/15 05:42:15 1.28
+++ modperl_callback.c2001/03/15 07:04:41 1.29
@@ -282,11 +282,9 @@
SvREFCNT_dec((SV*)av_args);
#ifdef USE_ITHREADS
-if (interp MpInterpPUTBACK_On(interp)) {
-/* XXX: might want to put interp back into available pool
- * rather than have it marked as in_use for the lifetime of
- * a request
- */
+if (interp MpInterpPUTBACK(interp)) {
+/* PerlInterpLifetime handler */
+modperl_interp_unselect(interp);
}
#endif
1.22 +16 -5 modperl-2.0/src/modules/perl/modperl_config.c
Index: modperl_config.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_config.c,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- modperl_config.c 2001/03/15 02:17:35 1.21
+++ modperl_config.c 2001/03/15 07:04:41 1.22
@@ -234,7 +234,7 @@
#ifdef USE_ITHREADS
static const char *MP_interp_lifetime_desc[] = {
-"undef", "subrequest", "request", "connection",
+"undef", "handler", "subrequest", "request", "connection",
};
const char *modperl_interp_lifetime_desc(modperl_interp_lifetime_e lifetime)
@@ -242,14 +242,20 @@
return MP_interp_lifetime_desc[lifetime];
}
-#define MP_INTERP_LIFETIME_OPTS "PerlInterpLifetime must be one of "
+#define MP_INTERP_LIFETIME_USAGE "PerlInterpLifetime must be one of "
#define MP_INTERP_LIFETIME_DIR_OPTS \
-MP_INTERP_LIFETIME_OPTS "subrequest or request"
+"handler, subrequest or request"
+#define MP_INTERP_LIFETIME_DIR_USAGE \
+MP_INTERP_LIFETIME_USAGE MP_INTERP_LIFETIME_DIR_OPTS
+
#define MP_INTERP_LIFETIME_SRV_OPTS \
-MP_INTERP_LIFETIME_OPTS "subrequest, request or connection"
+"connection, " MP_INTERP_LIFETIME_DIR_OPTS
+#define MP_INTERP_LIFETIME_SRV_USAGE \
+MP_INTERP_LIFETIME_USAGE MP_INTERP_LIFETIME_SRV_OPTS
+
MP_DECLARE_SRV_CMD(interp_lifetime)
{
modperl_interp_lifetime_e *lifetime;
@@ -260,6 +266,11 @@
lifetime = is_per_dir ? dcfg-interp_lifetime : scfg-interp_lifetime;
switch (toLOWER(*arg)) {
+ case 'h':
+if (strcaseEQ(arg, "handler")) {
+*lifetime = MP_INTERP_LIFETIME_HANDLER;
+break;
+}
case 's':
if (strcaseEQ(arg, "subrequest")) {
*lifetime = MP_INTERP_LIFETIME_SUBREQUEST;
@@ -277,7 +288,7 @@
}
default:
return is_per_dir ?
-MP_INTERP_LIFETIME_DIR_OPTS : MP_INTERP_LIFETIME_SRV_OPTS;
+MP_INTERP_LIFETIME_DIR_USAGE : MP_INTERP_LIFETIME_SRV_USAGE;
};
return NULL;
1.20 +3 -0 modperl-2.0/src/modules/perl/modperl_config.h
Index: modperl_config.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_config.h,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- modperl_config.h 2001/03/14 08:22:48 1.19
+++ modperl_config.h 2001/03/15 07:04:41 1.20
@@ -40,6 +40,9 @@
#define modperl_interp_lifetime_undef(dcfg) \
(dcfg-interp_lifetime == MP_INTERP_LIFETIME_UNDEF)
+#define modperl_interp_lifetime_handler(dcfg) \
+(dcfg-interp_lifetime == MP_INTERP_LIFETIME_HANDLER)
+
#define modperl_interp_lifetime_subrequest(dcfg) \
(dcfg-interp_lifetime == MP_INTERP_LIFETIME_SUBREQUEST)
1.25 +25 -14modperl-2.0/src/modules/perl/modperl_interp.c
Index: modperl_interp.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_interp.c,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- modperl_interp.c 2001/03/15 04:34:04 1.24
+++ modperl_interp.c 2001/03/15 07:04:41 1.25
@@ -189,6 +189,7 @@
modperl_interp_pool_t *mip = interp-mip;
MpInterpIN_USE_Off(interp);
+MpInterpPUTBACK_Off(interp);
modperl_tipool_putback_data(mip-tipool, data, interp-num_requests);
@@ -237,6 +238,9 @@
MP_TRACE_i(MP_FUNC, "lifetime is per-%s\n",
modperl_interp_lifetime_desc(lifetime));
+/*
+ *
cvs commit: modperl-2.0/src/modules/perl modperl_config.c
dougm 01/03/14 23:21:14
Modified:src/modules/perl modperl_config.c
Log:
make per-dir merger do something more useful
Revision ChangesPath
1.24 +16 -6 modperl-2.0/src/modules/perl/modperl_config.c
Index: modperl_config.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_config.c,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- modperl_config.c 2001/03/15 07:11:36 1.23
+++ modperl_config.c 2001/03/15 07:21:14 1.24
@@ -30,19 +30,32 @@
return dcfg;
}
+#define merge_item(item) \
+mrg-item = add-item ? add-item : base-item
+
void *modperl_merge_dir_config(apr_pool_t *p, void *basev, void *addv)
{
-#if 0
modperl_dir_config_t
*base = (modperl_dir_config_t *)basev,
*add = (modperl_dir_config_t *)addv,
*mrg = modperl_dir_config_new(p);
-#endif
MP_TRACE_d(MP_FUNC, "basev==0x%lx, addv==0x%lx\n",
(unsigned long)basev, (unsigned long)addv);
+
+#ifdef USE_ITHREADS
+merge_item(interp_lifetime);
+#endif
+
+{ /* XXX: should do a proper merge of the arrays */
+ /* XXX: and check if Perl*Handler is disabled */
+int i;
+for (i=0; iMP_PER_DIR_NUM_HANDLERS; i++) {
+merge_item(handlers[i]);
+}
+}
-return addv;
+return mrg;
}
modperl_request_config_t *modperl_request_config_new(request_rec *r)
@@ -147,9 +160,6 @@
return scfg;
}
-
-#define merge_item(item) \
-mrg-item = add-item ? add-item : base-item
/* XXX: this is not complete */
void *modperl_merge_srv_config(apr_pool_t *p, void *basev, void *addv)
