You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Vsevolod (Simon) Ilyushchenko" <si...@cshl.edu> on 2003/04/22 01:03:02 UTC
[mp2]How to get $r?
Hi,
This has probably been answered a hundred times, but I can't find
anything in the mod_perl2 guide or on the Net.
Under mod_perl 1, I could say
use Apache;
my $r = Apache->request()
to get at the request object from a script run under mod_perl.
The mod_perl 2 docs always give an example starting with
sub handler
{
my $r = shift;
}
However, if a script is run under ModPerl::Registry::handler, I don't
have a handler() method, and the Apache2 module does not have the
request() method any more. How do I get the $r variable?
Thanks,
Simon
--
Simon (Vsevolod ILyushchenko) simonf@cshl.edu
http://www.simonf.com
America's business leaders simply don't want to think
about complex technology issues - they want to think
about golf. Microsoft promises them that.
Andrew Grygus, www.aaxnet.com
Re: [mp2]How to get $r?
Posted by Stas Bekman <st...@stason.org>.
chris@prather.org wrote:
[...]
>>>Would you encounter the same
>>>problem if two or more threads required access to the single global $r?
>>
>>By default variables are *not* shared in ithreaded perl, please refer to the
>>perlthrtut manpage in perl 5.8.0.
>
>
> Knew I shouldn't put stupid user questions here. My apologies.
That's not a stupid question. Perl 5.8.0's ithreads architecture is quite
different from all other existing threads architectures with regards to
variables sharing.
>>>>In order not to shift of an occasional @ARGV, you probably can do:
>>>>
>>>>my $r;
>>>>$r = shift if $ENV{MOD_PERL};
>>>
>>>
>>>This isn't really the problem either the problem is it's not always convient to pass the
>>>request object. Basically what you're telling us is that we'll have to write our own
>>>infrastructure to get global access to $r in a elegant fashion because Apache-
>>>request() (under threads) has gone the way of the buffalo. To me this is fine, but
>>>Stas is there some place where it explains exactly why this is the case?
>>
>>Again, Apache->request() is there, but its usage is deprecated.
>
>
> Yeah but using deprecated methods is a no-no. ::grin:: The local storage
> explanation satisfies me there, I'll look at what I can do to write an explanation
> about it and submit a doc patch.
It's deprecated in a sense of suggesting to avoid using it, not in a sense of
an API that's scheduled to be removed in the future versions. May be a
different termin should be used.
> Back to the original post/question there are probably ways to get around it, like
> adding a handler in your external package that simply captures $r. But I have no
> clue how this would perform under threaded perl (or non-threaded mod_perl 2)
It'll work all the same under threaded and non-threaded mpms, as long as you
don't mess with threads by yourself. For example see our efforts to refurbish
CGI.pm and CGI/Cookie.pm not to rely on Apache->request and
$r->subprocess_env, but instead to accept $r as an argument. It looks like
Lincoln hasn't released 2.92 yet, but see the recent thread on this list where
he has posted a release candidate. Another good example is Apache::Request
which accepts $r as an argument to its initialization function.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2]How to get $r?
Posted by Perrin Harkins <pe...@elem.com>.
chris@prather.org wrote:
> Back to the original post/question there are probably ways to get around it, like
> adding a handler in your external package that simply captures $r. But I have no
> clue how this would perform under threaded perl (or non-threaded mod_perl 2)
>
> package FooBar;
>
> our $r;
>
> sub fixup_handler {
> $r = shift;
> }
>
> sub FOO { [do something with $r here] }
This looks a little scary to me. What are the implications of a request
object never going out of scope? Will you get strange results when the
object gets killed at the end of the request? The idea of putting a
request object in a global worries me for the same reason.
It's pretty typical for an application to pass around some kind of
pointer to the current state. Java servlets do it, and other frameworks
do as well. If you're building something with an OO interface, you can
avoid needing to pass $r after the initial call to new on each request:
Package FooBar;
sub new {
my ($class, $r) = @_;
my $self = { '_request' => $r };
bless $self, $class;
return $self;
}
sub do_something {
my $self = shift;
my $r = $self->{'_request'};
... do something with $r ...
}
I know that doesn't solve everything, but it's a technique that I've
seen people use with DBI handles successfully.
- Perrin
Re: [mp2]How to get $r?
Posted by ch...@prather.org.
On 24 Apr 2003 at 9:34, Stas Bekman wrote:
> IMHO, mp1 has spoiled people with Apache->request. It provides you a global
> request record, whereas you should maintain it by yourself if you want it
> global. $r is *always* passed to the handler, so you can always have it and
> just need to pass it around or keep it global by yourself.
It's because it's a nice feature. I didn't really appreciate it until two years in, and
having it makes a lot of things much easier.
> The only real need for it was for cgi scripts that needed to be run
> unmodified. But you can write cgi scripts that will run with and without
> mod_perl the same way and still get $r without using Apache->request.
>
> Remember that any registry script converts the script:
>
> print "Content-type: text/plain";
> print "Hello"
>
> into:
>
> package FOoo;
> sub handler {
> print "Content-type: text/plain";
> print "Hello"
> return OK;
> }
>
> and this handler always receives $r as an argument, so if you change your
> script to be:
<snip />
> under mod_perl, and will work all the same under mod_cgi.
This isn't really the point of either my questions (I'm trying to figure it out so I can
help explain it) or the original question which was regarding building an external
package that could be used in either enviroment, with I'd assume some 'extra'
benefits beyond simply code caching when run in the mod_perl enviroment.
> > Depending on the situation you may or may not want to pass $r, take the following
> > example:
> >
> > Take this (very simple) example:
> >
> > package MyPackage;
> > use FooBar # exports FOO and BAR
> >
> > sub handler {
> > my $r = shift;
> > FOO if $r->uri =~ /foo$;
> > BAR if $r->bar =~ /bar$;
> > };
> >
> > package FooBar;
> >
> > sub FOO {
> > my $r = Apache->request();
> > ...
> > }
>
> So pass $r as an argument!
>
> FOO($r) if $r->uri =~ /foo$;
That totally misses the point though. The idea is you don't want to force the end
user to pass the argument. You have however said you can't get there from here
this way. That's cool.
> and if you are really that lazy, make a global by yourself:
We've both agreed that globals are not the best solution. You'd have to assume that
the end user would put the right global in the right place, which is never a safe
assumption.
> package MyPackage;
> use FooBar # exports FOO and BAR
>
> my $gr;
> sub handler {
> $gr = shift;
> FOO if $gr->uri =~ /foo$;
> BAR if $gr->bar =~ /bar$;
> };
>
> package FooBar;
>
> sub FOO {
> my $r = $gr;
> ...
> }
>
> > I have some real world examples very similar to this where the code is cleaner and
> > easier to read if I don't pass $r. Basically you're saying you can't do the above in a
> > threaded enviroment (and I know from other e-mails/conversations I've overheard
> > it's because you'd have to copy $r to every thread ... bleh).
>
> You can do it in the threaded environment, it's just expensive to read and
> write from the thread's local storage.
Which is really the answer I was looking for. I'm sorry for causing the rest of the
ruckus.
> What I'm trying to do is to make sure that standard CPAN modules don't use
> expensive operations, when they can avoid them. In your private code you can
> choose to do absolutely anything you want ;)
What I am (and I think the original poster was) trying to do is figure out how to write
CPAN modules that are as easy on the end user (in this case joe bob mod_perl/CGI
developer) as possible while giving the most flexibility.
> > Would you encounter the same
> > problem if two or more threads required access to the single global $r?
>
> By default variables are *not* shared in ithreaded perl, please refer to the
> perlthrtut manpage in perl 5.8.0.
Knew I shouldn't put stupid user questions here. My apologies.
> >>In order not to shift of an occasional @ARGV, you probably can do:
> >>
> >>my $r;
> >>$r = shift if $ENV{MOD_PERL};
> >
> >
> > This isn't really the problem either the problem is it's not always convient to pass the
> > request object. Basically what you're telling us is that we'll have to write our own
> > infrastructure to get global access to $r in a elegant fashion because Apache-
> > request() (under threads) has gone the way of the buffalo. To me this is fine, but
> > Stas is there some place where it explains exactly why this is the case?
>
> Again, Apache->request() is there, but its usage is deprecated.
Yeah but using deprecated methods is a no-no. ::grin:: The local storage
explanation satisfies me there, I'll look at what I can do to write an explanation
about it and submit a doc patch.
Back to the original post/question there are probably ways to get around it, like
adding a handler in your external package that simply captures $r. But I have no
clue how this would perform under threaded perl (or non-threaded mod_perl 2)
package FooBar;
our $r;
sub fixup_handler {
$r = shift;
}
sub FOO { [do something with $r here] }
> > An e-mail offlist (or on) to me explaining it and I'll could write a doc patch to the
> > perl.apache.org site. I've heard this question enough to realize that this will be a
> > larger issue than not.
>
> Once I'll get around working on the docs, I'll document it unless someone will
> beat it to me.
Just trying to help. You've provided what I was looking for I believe. I'll see what I
can do to turn this into something reasonably solid.
-Chris
Re: [mp2]How to get $r?
Posted by Stas Bekman <st...@stason.org>.
IMHO, mp1 has spoiled people with Apache->request. It provides you a global
request record, whereas you should maintain it by yourself if you want it
global. $r is *always* passed to the handler, so you can always have it and
just need to pass it around or keep it global by yourself.
The only real need for it was for cgi scripts that needed to be run
unmodified. But you can write cgi scripts that will run with and without
mod_perl the same way and still get $r without using Apache->request.
Remember that any registry script converts the script:
print "Content-type: text/plain";
print "Hello"
into:
package FOoo;
sub handler {
print "Content-type: text/plain";
print "Hello"
return OK;
}
and this handler always receives $r as an argument, so if you change your
script to be:
my $r;
$r = shift if $ENV{MOD_PERL};
print "Content-type: text/plain";
print "Hello"
it'll really be:
package FOoo;
sub handler {
my $r;
$r = shift if $ENV{MOD_PERL};
print "Content-type: text/plain";
print "Hello"
return OK;
}
under mod_perl, and will work all the same under mod_cgi.
chris@prather.org wrote:
> On 23 Apr 2003 at 9:58, Stas Bekman wrote:
>
>
>>What difference does this make:
>>
>>my $r = shift;
>>
>>or
>>
>>my $r = Apache->request;
>>
>>?
>
>
> Depending on the situation you may or may not want to pass $r, take the following
> example:
>
> Take this (very simple) example:
>
> package MyPackage;
> use FooBar # exports FOO and BAR
>
> sub handler {
> my $r = shift;
> FOO if $r->uri =~ /foo$;
> BAR if $r->bar =~ /bar$;
> };
>
> package FooBar;
>
> sub FOO {
> my $r = Apache->request();
> ...
> }
So pass $r as an argument!
FOO($r) if $r->uri =~ /foo$;
and if you are really that lazy, make a global by yourself:
package MyPackage;
use FooBar # exports FOO and BAR
my $gr;
sub handler {
$gr = shift;
FOO if $gr->uri =~ /foo$;
BAR if $gr->bar =~ /bar$;
};
package FooBar;
sub FOO {
my $r = $gr;
...
}
> I have some real world examples very similar to this where the code is cleaner and
> easier to read if I don't pass $r. Basically you're saying you can't do the above in a
> threaded enviroment (and I know from other e-mails/conversations I've overheard
> it's because you'd have to copy $r to every thread ... bleh).
You can do it in the threaded environment, it's just expensive to read and
write from the thread's local storage.
What I'm trying to do is to make sure that standard CPAN modules don't use
expensive operations, when they can avoid them. In your private code you can
choose to do absolutely anything you want ;)
>>Just make sure that you put:
>>
>>my $r = shift;
>>
>>at the top of your script and pass it around, or make it global (however
>>remember to always initialize it if you use the global).
>
>
> If you've done the right thing and seperated your logic into different packages this
> isn't really an elegant solution is it?
Using global variables is almost never an elegant solution unless you can't
avoid it. May be it looks nice, but it'll bite your later.
> Also would this work in a threaded enviroment?
Yes.
> Would you encounter the same
> problem if two or more threads required access to the single global $r?
By default variables are *not* shared in ithreaded perl, please refer to the
perlthrtut manpage in perl 5.8.0.
>>In order not to shift of an occasional @ARGV, you probably can do:
>>
>>my $r;
>>$r = shift if $ENV{MOD_PERL};
>
>
> This isn't really the problem either the problem is it's not always convient to pass the
> request object. Basically what you're telling us is that we'll have to write our own
> infrastructure to get global access to $r in a elegant fashion because Apache-
> request() (under threads) has gone the way of the buffalo. To me this is fine, but
> Stas is there some place where it explains exactly why this is the case?
Again, Apache->request() is there, but its usage is deprecated.
> An e-mail offlist (or on) to me explaining it and I'll could write a doc patch to the
> perl.apache.org site. I've heard this question enough to realize that this will be a
> larger issue than not.
Once I'll get around working on the docs, I'll document it unless someone will
beat it to me.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2]How to get $r?
Posted by "Vsevolod (Simon) Ilyushchenko" <si...@cshl.edu>.
Stas,
> See my other reply, as there is no difference. And the code
>
> $r = shift if $ENV{MOD_PERL};
>
> will work all the same under mod_cgi. Please be more specific if that
> doesn't work for you.
I guess my point was (and Chris seemed to agree) that I'd like the cgi
script to be as easy as possible (there are other things for my target
user to worry about). I know it does not quite follow the Unix way which
suggests the universal and correct, if not always short, solution, but
not everybody out there sees the truth. :)
> This is ironic ;) Vsevolod, please take a bigger view of the world.
> While Apache->request seems to be the most imporatnt method to you,
> because you happen to use it a lot, some people are not using it at all,
> and they use other methods which seem to be the most important to them ;)
>
> Please don't get stressed about the lack of docs, all in its time.
> Instead, if you are unhappy about the way things are, do something and
> change them. Asking me to explain things offline to someone so that he
> can contribute it back as a patch is a funny request ;)
Please don't construe my request as whining. I am giving you feedback
that seems relevant in my little corner of the world. If there is nobody
else with the same request, feel free to ignore it. If it is a
legitimate request, somebody else will pipe in.
If I knew more about mod_perl, I would be glad to contribute. I don't
feel qualified right now, but in any case I appreciate your quick
answers on the list.
Simon
--
Simon (Vsevolod ILyushchenko) simonf@cshl.edu
http://www.simonf.com
America's business leaders simply don't want to think
about complex technology issues - they want to think
about golf. Microsoft promises them that.
Andrew Grygus, www.aaxnet.com
Re: [mp2]How to get $r?
Posted by Stas Bekman <st...@stason.org>.
Vsevolod (Simon) Ilyushchenko wrote:
>
>
> chris@prather.org wrote:
>
>> On 23 Apr 2003 at 9:58, Stas Bekman wrote:
>>
>>
>>> What difference does this make:
>>>
>>> my $r = shift;
>>>
>>> or
>>>
>>> my $r = Apache->request;
>>>
>>> ?
>>
>
> Big difference. I want to distribute a module and make it usable in
> whatever environment the user calls it, all without having to ask the
> user to invoke my module in different ways under different
> circumstances. You now, complexity hiding and all that jazz... :)
See my other reply, as there is no difference. And the code
$r = shift if $ENV{MOD_PERL};
will work all the same under mod_cgi. Please be more specific if that doesn't
work for you.
>> An e-mail offlist (or on) to me explaining it and I'll could write a
>> doc patch to the perl.apache.org site. I've heard this question enough
>> to realize that this will be a larger issue than not.
>
>
> I would, for one, appreciate it.
>
> I see that MethodLookup would give me the correct answer, but it's not
> yet the part of mod_perl in RedHat 9.0 (and I usually do not compile
> mod_perl myself, lazy bum that I am). Plus, for me Apache->request() is
> probably the most important method in mod_perl, so I hope it's worth a
> few minutes of someone's time to "cache" the answer in the docs. Then it
> could be found by Google, hopefully, which *will* save a lot of time for
> many people.
This is ironic ;) Vsevolod, please take a bigger view of the world. While
Apache->request seems to be the most imporatnt method to you, because you
happen to use it a lot, some people are not using it at all, and they use
other methods which seem to be the most important to them ;)
Please don't get stressed about the lack of docs, all in its time. Instead, if
you are unhappy about the way things are, do something and change them. Asking
me to explain things offline to someone so that he can contribute it back as a
patch is a funny request ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: where to ask questions about modperl1/apache1.3?
Posted by Perrin Harkins <pe...@elem.com>.
Will Trillich wrote:
> where can us stodgy old-code users go for help on apache 1.3 and
> modperl v1?
Here. I think the main reason you haven't received a lot of responses
to your questions is because you asked about <Perl> sections, which are
not very widely used.
- Perrin
RE: Apache::DProf with Apache 2.0
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi there,
On Wed, 23 Apr 2003, Mike Zelina wrote:
> 5.8... using the distribution from:
>
> http://theoryx5.uwinnipeg.ca/pub/other/Perl-5.8-win32-bin.exe
You're using *Windoze* ??
73,
Ged.
RE: Apache::DProf with Apache 2.0
Posted by Mike Zelina <mi...@zdginc.com>.
5.8... using the distribution from:
http://theoryx5.uwinnipeg.ca/pub/other/Perl-5.8-win32-bin.exe
Mike
> -----Original Message-----
> From: Ged Haywood [mailto:ged@www2.jubileegroup.co.uk]
> Sent: Wednesday, April 23, 2003 12:59 PM
> To: Mike Zelina
> Cc: Perrin Harkins; modperl@perl.apache.org
> Subject: RE: Apache::DProf with Apache 2.0
>
>
> Hi there,
>
> On Wed, 23 Apr 2003, Mike Zelina wrote:
>
> > it still crashes
>
> What version of Perl are you using?
>
> 73,
> Ged.
>
RE: Apache::DProf with Apache 2.0
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi there,
On Wed, 23 Apr 2003, Mike Zelina wrote:
> it still crashes
What version of Perl are you using?
73,
Ged.
RE: Apache::DProf with Apache 2.0
Posted by Mike Zelina <mi...@zdginc.com>.
>
> Apache::Dprof has not been ported for mod_perl 2 yet. You could try
> using the regular Devel::Dprof module instead, by setting PERL5OPT as
> described here:
> http://perl.apache.org/docs/1.0/guide/performance.html#Code_Profiling_Techniques
>
Thanks for the tip. I tried that out and it still crashes in the same
spot. Here's the Disassembly code if anyone wants to take a peek. It
crashes at the last line:
475: fprintf(fp, "#fOrTyTwO\n" );
010C241C push offset profstack_max+2BCh (010c66d4)
010C2421 mov eax,[fp (010c69f8)]
010C2426 push eax
010C2427 call dword ptr [__imp__fprintf (010c721c)]
010C242D add esp,8
Here's the fp pointer dump:
- fp 0x007a0a50
- _ptr 0x007b7764 "Uii"
-36 'U'
_cnt 0
- _base 0x00000000 ""
CXX0030: Error: expression cannot be evaluated
_flag 0
_file 0
_charbuf 0
_bufsiz 0
- _tmpfname 0x00000000 ""
CXX0030: Error: expression cannot be evaluated
Should I take a stab at debugging Apache::DProf for 2.0? Or is
that gonna be a huge can of worms that only someone who dreams in
XS can handle??
> -----Original Message-----
> From: Perrin Harkins [mailto:perrin@elem.com]
> Sent: Tuesday, April 22, 2003 11:08 AM
> To: Mike Zelina
> Cc: modperl@perl.apache.org
> Subject: Re: Apache::DProf with Apache 2.0
>
>
> Mike Zelina wrote:
> > Has anyone had any luck running DProf with mod_perl 1.99 and
> > Apache 2.0 on Win32?
>
> Apache::Dprof has not been ported for mod_perl 2 yet. You could try
> using the regular Devel::Dprof module instead, by setting PERL5OPT as
> described here:
> http://perl.apache.org/docs/1.0/guide/performance.html#Code_Profiling_Techniques
>
> - Perrin
>
RE: Apache::DProf with Apache 2.0 - some progress
Posted by Mike Zelina <mi...@zdginc.com>.
> Devel::DProf creates an END block that writes the actual content to that
> file. Are END blocks working for you in general?
- I added some printf's in the END block to
>> I'm wondering if it's because I can't run Apache with -X on windows.
> Are you sure? I thought that was an apache 1.x thing.
- Yep. You are right. Even though it's not listed as a valid
option, it does start Apache in single user mode on Win32 also...
Here's what I am now getting in the output file. According to my
poor-mans-debugger printfs, I make it past the code where it should
be printing out the records. My guess is that the "I/O operation"
warning below is the root of my problems. I dug around for AcceptEx issues
but couldn't find anything related. Ring any bells?
[notice] Child 1096: Exit event signaled. Child process is ending.
[warn] (720995)The I/O operation has been aborted because of either a thread exit or an application request. :
winnt_accept: Asynchronous AcceptEx failed.
[notice] Child 1096: Released the start mutex
[notice] Child 1096: Waiting for 5 worker threads to exit.
[notice] Child 1096: All worker threads have exited.
[notice] Child 1096: Child process is exiting
Thanks for all the help! Hopefully, I can figure this out and contribute
back a version of DProf for 2.0...
Mike
> -----Original Message-----
> From: Perrin Harkins [mailto:perrin@elem.com]
> Sent: Wednesday, April 23, 2003 7:26 PM
> To: Mike Zelina
> Cc: modperl@perl.apache.org
> Subject: RE: Apache::DProf with Apache 2.0 - some progress
>
>
> On Wed, 2003-04-23 at 22:06, Mike Zelina wrote:
> > from the command line, it also crashed. So, I got brave and modified
> > the .xs code to use the new PerlIO stuff instead of fprintf for file
> > access. Voila! The command line now works like a champ... However,
> > the PerlModule include still isn't working. No more crashing... and
> > it actually creates the tmon.out with the initial header.
> > However, it never dumps any profiling info beyond the header.
>
> Devel::DProf creates an END block that writes the actual content to that
> file. Are END blocks working for you in general?
>
> Also, you may want to get the latest source from CVS.
>
> > I'm wondering if it's because I can't run Apache with -X on windows.
>
> Are you sure? I thought that was an apache 1.x thing.
>
> I expect strange things will happen if DProf starts profiling in
> multiple interpreters and then they all try to dump their results to
> that one file. Maybe you could just limit it to a single thread by
> changing the conf file?
>
> - Perrin
>
RE: Apache::DProf with Apache 2.0 - some progress
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2003-04-23 at 22:06, Mike Zelina wrote:
> from the command line, it also crashed. So, I got brave and modified
> the .xs code to use the new PerlIO stuff instead of fprintf for file
> access. Voila! The command line now works like a champ... However,
> the PerlModule include still isn't working. No more crashing... and
> it actually creates the tmon.out with the initial header.
> However, it never dumps any profiling info beyond the header.
Devel::DProf creates an END block that writes the actual content to that
file. Are END blocks working for you in general?
Also, you may want to get the latest source from CVS.
> I'm wondering if it's because I can't run Apache with -X on windows.
Are you sure? I thought that was an apache 1.x thing.
I expect strange things will happen if DProf starts profiling in
multiple interpreters and then they all try to dump their results to
that one file. Maybe you could just limit it to a single thread by
changing the conf file?
- Perrin
Re: Apache::DProf with Apache 2.0 - some progress
Posted by Stas Bekman <st...@stason.org>.
Mike Zelina wrote:
> Synopsis:
> - Perl v5.8.0 / Mod_perl 1.99 / Apache 2.0.43
> - Trying to get Apache::DProf to work by including:
>
> PerlModule Apache::DProf
>
> in my httpd.conf.
>
> Suggestions so far:
> - Use PERL5OPT on the command line instead.
>
> Using PERL5OPT had the same crashing problems. In addition, if I
> tried to run:
>
> perl -d:DProf [script]
Also notice that mp2 has a new directive, PerlSwitches:
http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlSwitches_
which can be used to pass arguments just like you do at the command line.
> from the command line, it also crashed. So, I got brave and modified
> the .xs code to use the new PerlIO stuff instead of fprintf for file
> access. Voila! The command line now works like a champ... However,
> the PerlModule include still isn't working. No more crashing... and
> it actually creates the tmon.out with the initial header.
> However, it never dumps any profiling info beyond the header.
>
> I'm wondering if it's because I can't run Apache with -X on windows.
> Has anyone gotten DProf working on any version of Apache/mod_perl in
> Windows?
>
> Is this discussion more appropriate for the development list??
It's fine here, I guess. I don't use winFU so I can't be much of help. Neither
I have tried Apache::DProf with 2.0 yet. However I'll soon release
Apache::Peek (once 1.99_09 is released), which uses perlio and non-perlio
solutions, I can send it to you if you think it'll help. Remember that perlio
is not always available.
And thanks for the porting efforts!
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
RE: Apache::DProf with Apache 2.0 - some progress
Posted by Mike Zelina <mi...@zdginc.com>.
Synopsis:
- Perl v5.8.0 / Mod_perl 1.99 / Apache 2.0.43
- Trying to get Apache::DProf to work by including:
PerlModule Apache::DProf
in my httpd.conf.
Suggestions so far:
- Use PERL5OPT on the command line instead.
Using PERL5OPT had the same crashing problems. In addition, if I
tried to run:
perl -d:DProf [script]
from the command line, it also crashed. So, I got brave and modified
the .xs code to use the new PerlIO stuff instead of fprintf for file
access. Voila! The command line now works like a champ... However,
the PerlModule include still isn't working. No more crashing... and
it actually creates the tmon.out with the initial header.
However, it never dumps any profiling info beyond the header.
I'm wondering if it's because I can't run Apache with -X on windows.
Has anyone gotten DProf working on any version of Apache/mod_perl in
Windows?
Is this discussion more appropriate for the development list??
Thanks,
Mike
> -----Original Message-----
> From: Perrin Harkins [mailto:perrin@elem.com]
> Sent: Tuesday, April 22, 2003 11:08 AM
> To: Mike Zelina
> Cc: modperl@perl.apache.org
> Subject: Re: Apache::DProf with Apache 2.0
>
>
> Mike Zelina wrote:
> > Has anyone had any luck running DProf with mod_perl 1.99 and
> > Apache 2.0 on Win32?
>
> Apache::Dprof has not been ported for mod_perl 2 yet. You could try
> using the regular Devel::Dprof module instead, by setting PERL5OPT as
> described here:
> http://perl.apache.org/docs/1.0/guide/performance.html#Code_Profiling_Techniques
>
> - Perrin
>
Re: Apache::DProf with Apache 2.0
Posted by Perrin Harkins <pe...@elem.com>.
Mike Zelina wrote:
> Has anyone had any luck running DProf with mod_perl 1.99 and
> Apache 2.0 on Win32?
Apache::Dprof has not been ported for mod_perl 2 yet. You could try
using the regular Devel::Dprof module instead, by setting PERL5OPT as
described here:
http://perl.apache.org/docs/1.0/guide/performance.html#Code_Profiling_Techniques
- Perrin
RE: Apache::DProf with Apache 2.0
Posted by Mike Zelina <mi...@zdginc.com>.
Oops. Forgot the log file entry from Apache/logs/error.log:
[Wed Apr 23 09:28:36 2003] [notice] Parent: Created child process 476
[Wed Apr 23 09:28:42 2003] [notice] Child 476: Child process is running
[notice] Apache::DB initialized in child 476
[Wed Apr 23 09:28:57 2003] [crit] master_main: create child process failed. Exiting.
[Wed Apr 23 09:28:57 2003] [notice] Parent: Forcing termination of child process 2333832
-----Original Message-----
From: Mike Zelina [mailto:mike.zelina@zdginc.com]
Sent: Wednesday, April 23, 2003 10:56 AM
To: modperl@perl.apache.org
Subject: Apache::DProf with Apache 2.0
Has anyone had any luck running DProf with mod_perl 1.99 and
Apache 2.0 on Win32? I downloaded the Apache/Perl distribution
from:
http://theoryx5.uwinnipeg.ca/pub/other/Perl-5.8-win32-bin.exe
Everything works great out of the box. I then downloaded and
installed Apache::DProf, Devel::DProf and Apache::DB. I added
the following to my .conf:
PerlModule Apache::DProf
When I try to start Apache, it crashes. I noticed it was failing
in DPROF.DLL, so I decided to compile it debug. Turns out, it's
crashing in prof_recordheader() when it trys to fprintf.
fprintf(fp, "#fOrTyTwO\n" );
fprintf(fp, "$hz=%d;\n", DPROF_HZ );
I actually tried closing and re-opening the file pointer but it
still crashes. The funny part is that the tmon.out file is
created in the logs/dprof/$$ directory... so it doesn't appear
to be an OS permissions thing. Maybe it's Apache's or Perl's
override of fprintf permissions that is causing the problem?
Thanks for any help...
Mike Z.
Apache::DProf with Apache 2.0
Posted by Mike Zelina <mi...@zdginc.com>.
Has anyone had any luck running DProf with mod_perl 1.99 and
Apache 2.0 on Win32? I downloaded the Apache/Perl distribution
from:
http://theoryx5.uwinnipeg.ca/pub/other/Perl-5.8-win32-bin.exe
Everything works great out of the box. I then downloaded and
installed Apache::DProf, Devel::DProf and Apache::DB. I added
the following to my .conf:
PerlModule Apache::DProf
When I try to start Apache, it crashes. I noticed it was failing
in DPROF.DLL, so I decided to compile it debug. Turns out, it's
crashing in prof_recordheader() when it trys to fprintf.
fprintf(fp, "#fOrTyTwO\n" );
fprintf(fp, "$hz=%d;\n", DPROF_HZ );
I actually tried closing and re-opening the file pointer but it
still crashes. The funny part is that the tmon.out file is
created in the logs\dprof\$$ directory... so it doesn't appear
to be an OS permissions thing. Maybe it's Apache's or Perl's
override of fprintf permissions that is causing the problem?
Thanks for any help...
Mike Z.
Re: where to ask questions about modperl1/apache1.3?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> which brings me to my question -- those of us using older, stable
> code will still have questions hither and yon (like mine about
> <Perl> versus "SetHandler" from yesterday). the new excitement is
> all about apache 2.0 and the latest modperl tweaks, but...
>
> where can us stodgy old-code users go for help on apache 1.3 and
> modperl v1?
this is still the primary place for mod_perl support, both for 1.0 and 2.0.
I wouldn't read too much into the fact that some of the more complex (or
wordy :) 1.0 questions take a while to get answered these days - the economy
being what it is, it's more and more difficult for people to contribute back
to the community.
--Geoff
where to ask questions about modperl1/apache1.3?
Posted by Will Trillich <wi...@midwestRepo.com>.
On Wed, Apr 23, 2003 at 11:25:17AM -0400, Perrin Harkins wrote:
> I'm afraid that if you want to use bleeding edge pre-release
> code (which is what mod_perl 2 is at this point), you do have
> to keep up. There was a new release today, and no one will
> want to hear bug reports about things that were already fixed
> in it.
which brings me to my question -- those of us using older, stable
code will still have questions hither and yon (like mine about
<Perl> versus "SetHandler" from yesterday). the new excitement is
all about apache 2.0 and the latest modperl tweaks, but...
where can us stodgy old-code users go for help on apache 1.3 and
modperl v1?
--
will trillich
mayhugh services
Re: [mp2]How to get $r?
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2003-04-23 at 10:49, Vsevolod (Simon) Ilyushchenko wrote:
> I see that MethodLookup would give me the correct answer, but it's not
> yet the part of mod_perl in RedHat 9.0 (and I usually do not compile
> mod_perl myself, lazy bum that I am).
I'm afraid that if you want to use bleeding edge pre-release code (which
is what mod_perl 2 is at this point), you do have to keep up. There was
a new release today, and no one will want to hear bug reports about
things that were already fixed in it.
- Perrin
Re: [mp2]How to get $r?
Posted by "Vsevolod (Simon) Ilyushchenko" <si...@cshl.edu>.
chris@prather.org wrote:
> On 23 Apr 2003 at 9:58, Stas Bekman wrote:
>
>
>>What difference does this make:
>>
>>my $r = shift;
>>
>>or
>>
>>my $r = Apache->request;
>>
>>?
Big difference. I want to distribute a module and make it usable in
whatever environment the user calls it, all without having to ask the
user to invoke my module in different ways under different
circumstances. You now, complexity hiding and all that jazz... :)
> An e-mail offlist (or on) to me explaining it and I'll could write a doc patch to the
> perl.apache.org site. I've heard this question enough to realize that this will be a
> larger issue than not.
I would, for one, appreciate it.
I see that MethodLookup would give me the correct answer, but it's not
yet the part of mod_perl in RedHat 9.0 (and I usually do not compile
mod_perl myself, lazy bum that I am). Plus, for me Apache->request() is
probably the most important method in mod_perl, so I hope it's worth a
few minutes of someone's time to "cache" the answer in the docs. Then it
could be found by Google, hopefully, which *will* save a lot of time for
many people.
Simon
--
Simon (Vsevolod ILyushchenko) simonf@cshl.edu
http://www.simonf.com
America's business leaders simply don't want to think
about complex technology issues - they want to think
about golf. Microsoft promises them that.
Andrew Grygus, www.aaxnet.com
Re: [mp2]How to get $r?
Posted by ch...@prather.org.
On 23 Apr 2003 at 9:58, Stas Bekman wrote:
>
> What difference does this make:
>
> my $r = shift;
>
> or
>
> my $r = Apache->request;
>
> ?
Depending on the situation you may or may not want to pass $r, take the following
example:
Take this (very simple) example:
package MyPackage;
use FooBar # exports FOO and BAR
sub handler {
my $r = shift;
FOO if $r->uri =~ /foo$;
BAR if $r->bar =~ /bar$;
};
package FooBar;
sub FOO {
my $r = Apache->request();
...
}
I have some real world examples very similar to this where the code is cleaner and
easier to read if I don't pass $r. Basically you're saying you can't do the above in a
threaded enviroment (and I know from other e-mails/conversations I've overheard
it's because you'd have to copy $r to every thread ... bleh).
> Just make sure that you put:
>
> my $r = shift;
>
> at the top of your script and pass it around, or make it global (however
> remember to always initialize it if you use the global).
If you've done the right thing and seperated your logic into different packages this
isn't really an elegant solution is it?
Also would this work in a threaded enviroment? Would you encounter the same
problem if two or more threads required access to the single global $r?
> In order not to shift of an occasional @ARGV, you probably can do:
>
> my $r;
> $r = shift if $ENV{MOD_PERL};
This isn't really the problem either the problem is it's not always convient to pass the
request object. Basically what you're telling us is that we'll have to write our own
infrastructure to get global access to $r in a elegant fashion because Apache-
>request() (under threads) has gone the way of the buffalo. To me this is fine, but
Stas is there some place where it explains exactly why this is the case?
An e-mail offlist (or on) to me explaining it and I'll could write a doc patch to the
perl.apache.org site. I've heard this question enough to realize that this will be a
larger issue than not.
-Chris
Re: [mp2]How to get $r?
Posted by Stas Bekman <st...@stason.org>.
Vsevolod (Simon) Ilyushchenko wrote:
> Stas,
>
> Thanks for your answer. That's what I was looking for.
>
>> You can still do that with mp2, but you should avoid doing that if you
>> ever plan to run the threaded mpm.
>
>
> Exactly - I want to do it the right way.
>
>> Of course you do. ModPerl::Registry creates this handle for you. So if
>> you start your script with:
>>
>> my $r = shift;
>>
>> you will get $r passed to it.
>
>
> I am writing a module that should work both under mod_perl and without
> it, and I don't want to burden the user with having to get $r and pass
> it to the module.
What difference does this make:
my $r = shift;
or
my $r = Apache->request;
?
Just make sure that you put:
my $r = shift;
at the top of your script and pass it around, or make it global (however
remember to always initialize it if you use the global).
In order not to shift of an occasional @ARGV, you probably can do:
my $r;
$r = shift if $ENV{MOD_PERL};
>> mp2 does have the request() method, you simply haven't loaded the
>> module that contains it:
>>
>> (with installed mod_perl cvs:)
>> % perl -MApache2 -MModPerl::MethodLookup -e print_method request
>> to use method 'request' add:
>> use Apache::RequestUtil ();
>>
>> perhaps you need to read:
>> http://perl.apache.org/docs/2.0/user/porting/porting.html
>> http://perl.apache.org/docs/2.0/user/porting/compat.html
>
>
> But I have! I just searched again - they do not even mention
> Apache::RequestUtil!
Sure it doesn't, There are several hundred methods in mod_perl 2.0, there is a
special module that does the lookup for you (available from mod_perl cvs) and
it's documented in both pages how to use it when mod_perl complains that it
can't find module foo.
http://perl.apache.org/docs/2.0/user/porting/porting.html#Using_C_ModPerl__MethodLookup__to_Discover_Which_mod_perl_2_0_Modules_Need_to_Be_Loaded
I'm also thinking to autogenerate a map file which will include all XS methods
and their modules, for those who can't be bothered to run the lookup command ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
RE: [mp2]How to get $r?
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
> > So is this a common problem? Is there a need, however minor,
> for a set of
> > Faux::Apache:: classes that could be brought in by fixing @INC
> that would
> > act like mod_perl's calling framework without actually being
> mod_perl (e.g.
> > using CGI, FastCGI, or HTTP::Daemon to run mod_perl handlers)?
>
> Marc,
>
> I won't mind having this framework - otherwise I have to check whether I
> am running under mod_perl AND then which version it is. The only problem
> I see is that some of the mod_perl functions cannot be implemented via
> CGI (AFAIU), and thus the module you propose can be confusing sometimes.
> It will have to either not provide these functions or return null
> values, and handling of either will require extra user code anyway.
Well that's certainly true of almost all portability efforts. If you want
to be portable you end up coding to the least common denominator. If you
want to use all the power of a particular platform you can't be portable.
C'est la vie.
I think most of the basic stuff can be simulated. It should be possible to
write non-trivial response handlers and have them fire in a variety of
environments other than mod_perl. I'm more concerned with whether this is
something that would be generally useful or whether it is just you'n'me.
The question of supporting mod_perl v1 vs. mod_perl v2 is more vexing. It
would be nice to just concentrate on v2 but I suppose that is somewhat
premature as it is still in development. Works pretty good so far IMHO.
Can't be THAT far from release.
mma
Re: [mp2]How to get $r?
Posted by "Vsevolod (Simon) Ilyushchenko" <si...@cshl.edu>.
> So is this a common problem? Is there a need, however minor, for a set of
> Faux::Apache:: classes that could be brought in by fixing @INC that would
> act like mod_perl's calling framework without actually being mod_perl (e.g.
> using CGI, FastCGI, or HTTP::Daemon to run mod_perl handlers)?
Marc,
I won't mind having this framework - otherwise I have to check whether I
am running under mod_perl AND then which version it is. The only problem
I see is that some of the mod_perl functions cannot be implemented via
CGI (AFAIU), and thus the module you propose can be confusing sometimes.
It will have to either not provide these functions or return null
values, and handling of either will require extra user code anyway.
Simon
--
Simon (Vsevolod ILyushchenko) simonf@cshl.edu
http://www.simonf.com
America's business leaders simply don't want to think
about complex technology issues - they want to think
about golf. Microsoft promises them that.
Andrew Grygus, www.aaxnet.com
RE: [mp2]How to get $r?
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
> > Of course you do. ModPerl::Registry creates this handle for you. So if
> > you start your script with:
> >
> > my $r = shift;
> >
> > you will get $r passed to it.
>
> I am writing a module that should work both under mod_perl and without
> it, and I don't want to burden the user with having to get $r and pass
> it to the module.
I have this pile of code that evolved based on requirements similar to this.
For example, I'm playing with mod_perl at home right now but my current
hosting ISP doesn't support it. So I have all these non-standard classes
that let me write once (_not_ via the Apache:: classes, I might add) run
elsewhere.
So is this a common problem? Is there a need, however minor, for a set of
Faux::Apache:: classes that could be brought in by fixing @INC that would
act like mod_perl's calling framework without actually being mod_perl (e.g.
using CGI, FastCGI, or HTTP::Daemon to run mod_perl handlers)?
I asked a week or so ago and no response, which I pretty much what I
expected. I'm often off in a different time zone all by my lonesome. But
here is someone else who looks like they have the same problem...which I
have more or less solved, albeit in an upside-down manner. I thought that I
would ask again.
mma
Re: [mp2]How to get $r?
Posted by "Vsevolod (Simon) Ilyushchenko" <si...@cshl.edu>.
Stas,
Thanks for your answer. That's what I was looking for.
> You can still do that with mp2, but you should avoid doing that if you
> ever plan to run the threaded mpm.
Exactly - I want to do it the right way.
> Of course you do. ModPerl::Registry creates this handle for you. So if
> you start your script with:
>
> my $r = shift;
>
> you will get $r passed to it.
I am writing a module that should work both under mod_perl and without
it, and I don't want to burden the user with having to get $r and pass
it to the module.
> mp2 does have the request() method, you simply haven't loaded the module
> that contains it:
>
> (with installed mod_perl cvs:)
> % perl -MApache2 -MModPerl::MethodLookup -e print_method request
> to use method 'request' add:
> use Apache::RequestUtil ();
>
> perhaps you need to read:
> http://perl.apache.org/docs/2.0/user/porting/porting.html
> http://perl.apache.org/docs/2.0/user/porting/compat.html
But I have! I just searched again - they do not even mention
Apache::RequestUtil!
Simon
--
Simon (Vsevolod ILyushchenko) simonf@cshl.edu
http://www.simonf.com
America's business leaders simply don't want to think
about complex technology issues - they want to think
about golf. Microsoft promises them that.
Andrew Grygus, www.aaxnet.com
Re: [mp2]How to get $r?
Posted by Stas Bekman <st...@stason.org>.
Vsevolod (Simon) Ilyushchenko wrote:
> Hi,
>
> This has probably been answered a hundred times, but I can't find
> anything in the mod_perl2 guide or on the Net.
>
> Under mod_perl 1, I could say
>
> use Apache;
> my $r = Apache->request()
>
> to get at the request object from a script run under mod_perl.
You can still do that with mp2, but you should avoid doing that if you ever
plan to run the threaded mpm.
> The mod_perl 2 docs always give an example starting with
> sub handler
> {
> my $r = shift;
> }
>
> However, if a script is run under ModPerl::Registry::handler, I don't
> have a handler() method,
Of course you do. ModPerl::Registry creates this handle for you. So if you
start your script with:
my $r = shift;
you will get $r passed to it.
> and the Apache2 module does not have the
> request() method any more. How do I get the $r variable?
mp2 does have the request() method, you simply haven't loaded the module that
contains it:
(with installed mod_perl cvs:)
% perl -MApache2 -MModPerl::MethodLookup -e print_method request
to use method 'request' add:
use Apache::RequestUtil ();
perhaps you need to read:
http://perl.apache.org/docs/2.0/user/porting/porting.html
http://perl.apache.org/docs/2.0/user/porting/compat.html
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com