Mailing List Archive

Hi,
>
> recently I switched from Embperl CGI- to mod_perl-Mode. However,
> some pages, which use e.g. [- require "xxx.pl" -], strangely refuse
> to work _sometimes_, that is, some accesses yield the correct
> HTML output, but on some requests, the Perl subroutines defined
> in xxx.pl are not visible in the page's namespace.
>
> It seems to me that xxx.pl is only available to _some_ Apache
> childs. How can I change this behaviour?
>

That's because now you have a persistent Perl interpreter. In CGI mode for
every request a new/fresh Perl interpreter is started. Under mod_perl not
and a file that is compiled in one namespace, isn't visible in another. I
append you a mail I send some time ago to the list, that should explain the
behaviour.

Gerald


> -----Original Message-----
> From: embperl-return-275-richter=ecos.de@perl.apache.org
> [mailto:embperl-return-275-richter=ecos.de@perl.apache.org]On Behalf Of
> Gerald Richter
> Sent: Friday, April 21, 2000 9:10 PM
> To: Ulrike Schepp; Steven D. Arnold
> Cc: Embperl Mailingliste
> Subject: RE: use module in Embperl (was: problem solved, but still
> weird!)
>
>
> >
> > Standard workaround here is now "apachectl restart" after the change of
> > modules :-/ weird but it really works!
> >
>
> Nothing weird here. Everything is well defined. Just let us try to
> understand how Perl, mod_perl and Embperl works together:
>
> "perldoc -f use" tells us:
>
> Imports some semantics into the current package from the named module,
> generally by aliasing certain subroutine or variable names into your
> package. It is exactly equivalent to
>
> BEGIN { require Module; import Module LIST; }
>
> except that Module must be a bareword.
>
> So what's important here for us is, that use executes a require
> and this is
> always done before any other code is executed.
>
> "perldoc -f require" says (among other things):
>
> ..., demands that a library file be included if it hasn't already
> been included.
>
> and
>
> Note that the file will not be included twice under the same specified
> name.
>
> So now we know (or should know) that mod_perl starts the Perl interpreter
> once when Apache is started and the Perl interpreter is only
> terminated when
> Apache is terminated. Out of these two things follows, that a
> module that is
> loaded via use or require is only loaded once and will never be reloaded,
> regardless if the source changes or not.
>
> So far this is just standard Perl. Things get's a little bit more
> difficult
> when running under mod_perl (only Unix), because Apache forks a
> set of child
> processes as neccessary and from the moment they are forked, they run on
> their own and don't know of each other. So if a module is loaded at server
> startup time (before the fork), it is loaded in all childs (this
> can be used
> to save memory, because the code will actually only reside once
> in memory),
> but when the modul is loaded inside the child and the source changes, it
> could be happen, that one child has loaded an ealier version and another
> child has loaded a later version of that module, depending on the time the
> module is actualy loaded by the child.
>
> That explains, why sometimes it works and sometimes it doesn't, simply
> because different childs has loaded different versions of the same module
> and when you reload your page you hit different childs of Apache!
>
> Now there is one point that is special to Embperl to add. Since Embperl
> compiles every page in a different namespace, a module that
> doesn't contains
> a "package foo" statement is compiled in the namespace of the
> page where it
> is first loaded. Because Perl will not load the module a second
> time, every
> other page will not see subs and vars that are defined in the
> loaded module.
> This could be simply avoided by giving every module that should be loaded
> via use/require an explicit namespace via the package statement.
>
> So what can we do?
> - If a module change, simply restart Apache. That's works always.
> - use Apache::StatInc. This will do a stat on every loaded module and
> compare the modification time. If the source has changed the module is
> reloaded. This works most times (but not all modules can be cleanly
> reloaded) and as the number of loaded modules increase, your
> sever will slow
> down, because of the stat it has to do for every module.
> - Use "do" instead of "require". do will execute your file everytime it is
> used. This also adds overhead, but this may be accpetable for
> small files or
> in a debugging environement. (NOTE: Be sure to check $@ after a
> do, because
> do works like eval)
>
> I hope now it's seem a little bit less weird..
>
> Gerald
>



-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------

Hi,

On Tue, 27 Jun 2000, Gerald Richter wrote:

> That's because now you have a persistent Perl interpreter. In CGI mode for
> every request a new/fresh Perl interpreter is started. Under mod_perl not
> and a file that is compiled in one namespace, isn't visible in another. I
> append you a mail I send some time ago to the list, that should explain the
> behaviour.

Thanks for your explanations, using "do" instead of "require" solves
the problem for me.

However, I guess I have found another small difference between CGI-
and mod_perl-based Embperl, regarding $escmode.

From my tests, I get the impression that setting $escmode in an
Embperl page also has impact on the $escmode setting in other
Embperl pages - that is, $escmode is _not_ resetted or set to a default
the beginning of every Embperl page.
For me, this results in a different escaping behaviour, depending on
the Apache child serving the request an on the $escmode setting of
the page served before.

Is this the "planned" behaviour of Embperl, or should it be considered
a bug or missing feature? May I set a default $escmode by using
PerlSetenv in httpd.conf?

_____

Thomas Corte
<thomas@knipp.de>

Hi,
>
>
> However, I guess I have found another small difference between CGI-
> and mod_perl-based Embperl, regarding $escmode.
>
> >From my tests, I get the impression that setting $escmode in an
> Embperl page also has impact on the $escmode setting in other
> Embperl pages - that is, $escmode is _not_ resetted or set to a default
> the beginning of every Embperl page.
> For me, this results in a different escaping behaviour, depending on
> the Apache child serving the request an on the $escmode setting of
> the page served before.
>
> Is this the "planned" behaviour of Embperl, or should it be considered
> a bug or missing feature?

It's neither a bug (of Embperl), nor a feature. I am very sure that Embperl
resets escmode to 3 upon start of _every_ request and that pages don't
impact each other(otherwise many of my pages won't work). There must be
another reason why this happens...

> May I set a default $escmode by using
> PerlSetenv in httpd.conf?
>

PerlSetEnv EMBPERL_ESCMODE 3

see "perldoc HTML::Embperl" :-)

Gerald


-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------

Hi,

On Tue, 27 Jun 2000, Gerald Richter wrote:

> It's neither a bug (of Embperl), nor a feature. I am very sure that Embperl
> resets escmode to 3 upon start of _every_ request and that pages don't
> impact each other(otherwise many of my pages won't work). There must be
> another reason why this happens...
>
> > May I set a default $escmode by using
> > PerlSetenv in httpd.conf?
> >
>
> PerlSetEnv EMBPERL_ESCMODE 3
>
> see "perldoc HTML::Embperl" :-)

Of course :-) - what I meant here is whether PerlSetEnv will bring back
a "deterministic" behaviour :)

I have set up a small test file (btw, $optRawInput is 1):

<html>
<head>
</head>
<body>
<p>escmode: [+ $escmode +]</p>
<p>PID: [+ $$ +]</p>
<p>[+ "test<br>test" +]</p>
</body>
</html>

Hitting reload in my browser, most of the time I get (as expected for
$escmode = default = 3):

escmode: 3

PID: 25903

test<br>test

However, sometimes I get

escmode: 0

PID: 25783

test
test

This occurs almost every time a new PID shows up, but sometimes also
on subsequent requests to the same apache child.

The effect goes away if I add [- $escmode = 3 -] at the top of
the file.

I use Embperl 1.2.1, mod_perl 1.21 and Apache 1.3.11 on HP-UX 11.

Maybe I've got another example of HP-UX weirdness here...

_____

Thomas Corte
<thomas@knipp.de>

>
> I use Embperl 1.2.1, mod_perl 1.21 and Apache 1.3.11 on HP-UX 11.
>

Is mod_perl build as DSO? If yes, upgrade to a newer mod_perl version and
your problems will go away...

Gerald


-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------

Hi,

On Wed, 28 Jun 2000, Gerald Richter wrote:

> >
> > I use Embperl 1.2.1, mod_perl 1.21 and Apache 1.3.11 on HP-UX 11.
> >
>
> Is mod_perl build as DSO? If yes, upgrade to a newer mod_perl version and
> your problems will go away...

No, mod_perl ist built into Apache statically here.
However, some other modules (SSL, rewrite) are used as DSOs, but this,
I assume, should not harm.

Nevertheless, I will consider upgrading to a higher mod_perl version.
Till then, I can get along by setting $escmode explicitly at the
top of every embperl page.

_____

Thomas Corte
<thomas@knipp.de>