You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2002/05/22 19:32:06 UTC
documenting SetHandler perl-script|modperl
We don't have the difference between
SetHandler perl-script
and
SetHandler modperl
documented.
Source code wise it seems that modperl_response_handler_cgi is what
makes them different. I've started documenting the difference, but I
don't understand everything and need help. Here is the start:
===
"perl-script" and "modperl" are both mod_perl handlers, but the latter
one (new to mod_perl 2.0) does less things than the former and therefore
more efficient.
SetHandler perl-script
implies:
* PerlOptions +GlobalRequest
* PerlOptions +SetupEnv unless PerlOption -SetupEnv is specified
* C<STDOUT>/C<STDOUT> get tied to the request object C<$r>, so you can
use CORE::print() or read from C<STDIN>.
* what happens to env in modperl_env_request_tie? is it simply to be
able to restore it to its previous state
* there are a few other things that happen in this function, what are
they?
Also what can we tell about "modperl" other than saying that it doesn't
do all the above things.
===
BTW, why modperl_env_request_populate() is called only for perl-script
handler and not for modperl?
Thanks!
__________________________________________________________________
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
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: documenting SetHandler perl-script|modperl
Posted by Stas Bekman <st...@stason.org>.
> BTW, why modperl_env_request_populate() is called only for perl-script
> handler and not for modperl?
I've figured this one out. That means that if you run under SetHandler
"modperl" there is no way to 'Options +SetupEnv' and "perl-script" is
the only option. I guess this is how it should be.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: documenting SetHandler perl-script|modperl
Posted by Doug MacEachern <do...@covalent.net>.
On Sun, 2 Jun 2002, Stas Bekman wrote:
> Does this also mean that with 'SetHandler modperl' the coder should be
> extremely careful not to pollute these globals and therefore we should
> add a warning in the relevant docs?
yes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: documenting SetHandler perl-script|modperl
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Doug MacEachern wrote:
>
> There is one item of your reply I need more details about:
>
>>> SetHandler perl-script
>>
> ...
>
>>> implies:
>>
> ...
>
>>> * there are a few other things that happen in this function, what are
>>> they?
>>
>>
>>
>> modperl_perl_global_request{save,restore} does something like local()
>> for all variables in the modperl_perl_global.c:MP_perl_global_entries
>> table.
>
>
> MP_perl_global_entries[] = {
> {"END", MP_GLOBAL_OFFSET(end), MP_GLOBAL_AVCV}, /* END */
>
> What's global END()? I thought END always belong to some namespace.
>
> {"ENV", MP_GLOBAL_OFFSET(env), MP_GLOBAL_GVHV}, /* %ENV */
> {"INC", MP_GLOBAL_OFFSET(inc), MP_GLOBAL_GVAV}, /* @INC */
> {"STDOUT", MP_GLOBAL_OFFSET(defout), MP_GLOBAL_GVIO}, /* $| */
> {"/", MP_GLOBAL_OFFSET(rs), MP_GLOBAL_SVPV}, /* $/ */
>
> so %ENV, @INC, $| on STDOUT and $/ are all getting reset at the end of
> request. It's clear with %ENV and @INC, but I don't understand why the
> latter two? why not put the responsibility of localizing these on a
> developer?
Does this also mean that with 'SetHandler modperl' the coder should be
extremely careful not to pollute these globals and therefore we should
add a warning in the relevant docs?
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: documenting SetHandler perl-script|modperl
Posted by Doug MacEachern <do...@covalent.net>.
On Sun, 2 Jun 2002, Stas Bekman wrote:
> MP_perl_global_entries[] = {
> {"END", MP_GLOBAL_OFFSET(end), MP_GLOBAL_AVCV}, /* END */
>
> What's global END()? I thought END always belong to some namespace.
nope. PL_endav is global.
> {"ENV", MP_GLOBAL_OFFSET(env), MP_GLOBAL_GVHV}, /* %ENV */
> {"INC", MP_GLOBAL_OFFSET(inc), MP_GLOBAL_GVAV}, /* @INC */
> {"STDOUT", MP_GLOBAL_OFFSET(defout), MP_GLOBAL_GVIO}, /* $| */
> {"/", MP_GLOBAL_OFFSET(rs), MP_GLOBAL_SVPV}, /* $/ */
>
> so %ENV, @INC, $| on STDOUT and $/ are all getting reset at the end of
> request. It's clear with %ENV and @INC, but I don't understand why the
> latter two? why not put the responsibility of localizing these on a
> developer?
because we do the same in 1.x.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: documenting SetHandler perl-script|modperl
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
There is one item of your reply I need more details about:
>> SetHandler perl-script
...
>>implies:
...
>>* there are a few other things that happen in this function, what are
>> they?
>
>
> modperl_perl_global_request{save,restore} does something like local() for
> all variables in the modperl_perl_global.c:MP_perl_global_entries table.
MP_perl_global_entries[] = {
{"END", MP_GLOBAL_OFFSET(end), MP_GLOBAL_AVCV}, /* END */
What's global END()? I thought END always belong to some namespace.
{"ENV", MP_GLOBAL_OFFSET(env), MP_GLOBAL_GVHV}, /* %ENV */
{"INC", MP_GLOBAL_OFFSET(inc), MP_GLOBAL_GVAV}, /* @INC */
{"STDOUT", MP_GLOBAL_OFFSET(defout), MP_GLOBAL_GVIO}, /* $| */
{"/", MP_GLOBAL_OFFSET(rs), MP_GLOBAL_SVPV}, /* $/ */
so %ENV, @INC, $| on STDOUT and $/ are all getting reset at the end of
request. It's clear with %ENV and @INC, but I don't understand why the
latter two? why not put the responsibility of localizing these on a
developer?
Thanks!
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: documenting SetHandler perl-script|modperl
Posted by Stas Bekman <st...@stason.org>.
"perl-script" is exactly what you've in 1.0
"modperl" is the bare bones. See the tests in t/ that run under
"modperl" and you will understand what's the difference.
SOme time in the future I'll run some benchmarks and will post the
results. modperl should be faster than "perl-script".
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl benchmarking (was Re: documenting SetHandler perl-script|modperl)
Posted by Stas Bekman <st...@stason.org>.
David Jacobs wrote:
> I've had trouble benchmarking some of my mod_perl scripts on my desktop.
> The http_load tool we usually use (all under RedHat) works fine with
> static pages or CGI, but when I use it on mod_perl scripts I get a "byte
> count wrong" error. This could be because of something unexpected in the
> header, or perhaps mod_perl doesn't like to be benchmarked? It makes no
> sense to me either :(
are you talking about mod_perl 1.0 or 2.0? I've recently used http_load
to do some benchmarking on 1.0 and haven't noticed any problems.
> What tools do you all use to benchmark web page performace?
http://perl.apache.org/release/docs/1.0/guide/performance.html#Benchmarking_Response_Times
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl benchmarking (was Re: documenting SetHandler
perl-script|modperl)
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 16:41 23.05.2002, David Jacobs wrote:
>I've had trouble benchmarking some of my mod_perl scripts on my desktop.
>The http_load tool we usually use (all under RedHat) works fine with
>static pages or CGI, but when I use it on mod_perl scripts I get a "byte
>count wrong" error. This could be because of something unexpected in the
>header, or perhaps mod_perl doesn't like to be benchmarked? It makes no
>sense to me either :(
>
>What tools do you all use to benchmark web page performace?
This should be discussed on the mod_perl users list.
See the performance docs,
http://perl.apache.org/release/docs/1.0/guide/performance.html
And especially the section on Benchmarking applications:
http://perl.apache.org/release/docs/1.0/guide/performance.html#Benchmarking_Applications
--
Per Einar Ellefsen
per.einar@skynet.be
mod_perl benchmarking (was Re: documenting SetHandler perl-script|modperl)
Posted by David Jacobs <dj...@cheetahmail.com>.
I've had trouble benchmarking some of my mod_perl scripts on my desktop.
The http_load tool we usually use (all under RedHat) works fine with
static pages or CGI, but when I use it on mod_perl scripts I get a "byte
count wrong" error. This could be because of something unexpected in the
header, or perhaps mod_perl doesn't like to be benchmarked? It makes no
sense to me either :(
What tools do you all use to benchmark web page performace?
tia
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: documenting SetHandler perl-script|modperl
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 00:23 23.05.2002, Issac Goldstand wrote:
>Per Einar Ellefsen wrote:
>
>>At 23:42 22.05.2002, Issac Goldstand wrote:
>>
>>>Doug MacEachern wrote:
>>>
>>>>On Thu, 23 May 2002, Stas Bekman wrote:
>>>>
>>>>>We don't have the difference between
>>>>> SetHandler perl-script
>>>>>and
>>>>> SetHandler modperl
>>>>>documented.
>>>>
>>>>
>>>>in a nutshell, 'perl-script' does everything it did in 1.x
>>>>'modperl' does nothing special, just the callback.
>>>
>>>callback? Can you elaborate a bit for the less educated? :-)
>>
>>
>>The callback to Perl*Handlers, ie. having mod_perl handle the request at
>>all, I suppose. Globally, what you'd expect from perl-script, but
>>perl-script does some more things behind the scenes.
>So basically, 'modperl' is raw mod_perl mode, while 'perl-script' enables
>lots of CGI emulations, on a very simple layer?
Well, perl-script == modperl + what perl-script traditionally did in 1.x,
but which isn't necessarily useful for mod_perl handlers.
--
Per Einar Ellefsen
per.einar@skynet.be
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: documenting SetHandler perl-script|modperl
Posted by Issac Goldstand <ma...@beamartyr.net>.
Per Einar Ellefsen wrote:
> At 23:42 22.05.2002, Issac Goldstand wrote:
>
>> Doug MacEachern wrote:
>>
>>> On Thu, 23 May 2002, Stas Bekman wrote:
>>>
>>>> We don't have the difference between
>>>> SetHandler perl-script
>>>> and
>>>> SetHandler modperl
>>>> documented.
>>>
>>>
>>> in a nutshell, 'perl-script' does everything it did in 1.x
>>> 'modperl' does nothing special, just the callback.
>>
>> callback? Can you elaborate a bit for the less educated? :-)
>
>
> The callback to Perl*Handlers, ie. having mod_perl handle the request
> at all, I suppose. Globally, what you'd expect from perl-script, but
> perl-script does some more things behind the scenes.
>
>
So basically, 'modperl' is raw mod_perl mode, while 'perl-script'
enables lots of CGI emulations, on a very simple layer?
Issac
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: documenting SetHandler perl-script|modperl
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 23:56 22.05.2002, Per Einar Ellefsen wrote:
>At 23:42 22.05.2002, Issac Goldstand wrote:
>>Doug MacEachern wrote:
>>
>>>On Thu, 23 May 2002, Stas Bekman wrote:
>>>
>>>>We don't have the difference between
>>>> SetHandler perl-script
>>>>and
>>>> SetHandler modperl
>>>>documented.
>>>
>>>in a nutshell, 'perl-script' does everything it did in 1.x
>>>'modperl' does nothing special, just the callback.
>>callback? Can you elaborate a bit for the less educated? :-)
>
>The callback to Perl*Handlers, ie. having mod_perl handle the request at
>all, I suppose. Globally, what you'd expect from perl-script, but
>perl-script does some more things behind the scenes.
Or rather, trying to sound more clear: installing the mod_perl callback for
Apache to dispatch the request to mod_perl instead of handling it itself.
And then mod_perl can handle Perl*Handler callbacks.
--
Per Einar Ellefsen
per.einar@skynet.be
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: documenting SetHandler perl-script|modperl
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 23:42 22.05.2002, Issac Goldstand wrote:
>Doug MacEachern wrote:
>
>>On Thu, 23 May 2002, Stas Bekman wrote:
>>
>>>We don't have the difference between
>>> SetHandler perl-script
>>>and
>>> SetHandler modperl
>>>documented.
>>
>>in a nutshell, 'perl-script' does everything it did in 1.x
>>'modperl' does nothing special, just the callback.
>callback? Can you elaborate a bit for the less educated? :-)
The callback to Perl*Handlers, ie. having mod_perl handle the request at
all, I suppose. Globally, what you'd expect from perl-script, but
perl-script does some more things behind the scenes.
--
Per Einar Ellefsen
per.einar@skynet.be
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: documenting SetHandler perl-script|modperl
Posted by Issac Goldstand <ma...@beamartyr.net>.
Doug MacEachern wrote:
>On Thu, 23 May 2002, Stas Bekman wrote:
>
>>We don't have the difference between
>> SetHandler perl-script
>>and
>> SetHandler modperl
>>documented.
>>
>
>in a nutshell, 'perl-script' does everything it did in 1.x
>'modperl' does nothing special, just the callback.
>
callback? Can you elaborate a bit for the less educated? :-)
Issac
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: documenting SetHandler perl-script|modperl
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 23 May 2002, Stas Bekman wrote:
> We don't have the difference between
> SetHandler perl-script
> and
> SetHandler modperl
> documented.
in a nutshell, 'perl-script' does everything it did in 1.x
'modperl' does nothing special, just the callback.
> implies:
>
> * PerlOptions +GlobalRequest
hadn't been doing that, but it does now unless PerlOption -GlobalRequest
is specified.
> * PerlOptions +SetupEnv unless PerlOption -SetupEnv is specified
right.
> * C<STDOUT>/C<STDOUT> get tied to the request object C<$r>, so you can
> use CORE::print() or read from C<STDIN>.
right.
> * what happens to env in modperl_env_request_tie?
nothing, yet.
> * there are a few other things that happen in this function, what are
> they?
modperl_perl_global_request{save,restore} does something like local() for
all variables in the modperl_perl_global.c:MP_perl_global_entries table.
> Also what can we tell about "modperl" other than saying that it doesn't
> do all the above things.
nothing else.
> ===
>
> BTW, why modperl_env_request_populate() is called only for perl-script
> handler and not for modperl?
because the 'modperl' handler does nothing special.
if you want it, call $r->subprocess_env in void context or use perl-script
handler.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org