You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Andrew Chen <ac...@cobaltgroup.com> on 2000/07/13 20:51:14 UTC
PerlRun question
Hi, I'm researching the nicest way to migrate our CGIs to running under
mod_perl, and although they are too dirty to run under Apache::Registry,
Apache::PerlRun works just fine.
There is the distinction between PerlRun with PerlRunOnce On and
PerlRunOnce Off. With it off there is a big speed boost, but our code is
dirty (and huge) and there are many instances where people don't declare
their variables without using them. So now the migration strategy revolves
around getting everything to PerlRun with PerlRunOnce Off.
There are two potential migration strategies:
The first one is that we have two types of files that are handled
differently, *.cgi (handled under PerlRun with PerlRunOnce On) and then
*.pr (handled under PerlRun with PerlRunOnce Off). The idea is that
everything runs under *.cgi in the beginning (which is the first step of
the migration), and then we slowly clean up files and put them into *.pr
files. The main problem is that because there's lots of references to
*.cgi everywhere, every file we cleaned up and renamed to *.pr would have
to have all of its referrers changed to do that (that's a lot of work).
The way around that would be to have ErrorDocument be a script that checks
that if a *.cgi file is requested, if a *.pr file is there then it is
redirected to this. This has problems as well, the main one being that
POST operations do not get "redirected" properly. Any obvious ways to
solve this problem?
The second strategy is to get mod_perl to compromise between the effects
of PerlRunOnce On and PerlRunOnce Off. Is there an easy for for PerlRun to
flush everything (including packages) that wasn't preloaded in the
startup.pl file? That would be a compromise between killing the child
everytime and keeping all the packages around.
Please help me with this! My internship depends on it! :) Thanks everyone.
Andrew Chen
Intern, Architecture
achen@cobaltgroup.com
206-219-8445
The Cobalt Group, Inc.
Re: PerlRun question
Posted by Honza Pazdziora <ad...@informatics.muni.cz>.
On Thu, Jul 13, 2000 at 08:12:54PM +0100, David Hodgkinson wrote:
>
> How dirty is dirty?
>
> If it's a case of assembling the globals into a big "use vars qw//"
> then that's OK. Boring but do-able.
There are problems like
$action = 'save' if $q->param('action') eq 'save';
We have a lot of such uses of globals in scripts here, and the problem
is that nor -w nor use strict catches such problems. PerlRunOnce works
just fine, except that forking new process for each request is still
rather slow.
--
------------------------------------------------------------------------
Honza Pazdziora | adelton@fi.muni.cz | http://www.fi.muni.cz/~adelton/
.project: Perl, DBI, Oracle, MySQL, auth. WWW servers, MTB, Spain.
Petition for a Software Patent Free Europe http://petition.eurolinux.org
------------------------------------------------------------------------
Re: PerlRun question
Posted by Perrin Harkins <pe...@primenet.com>.
On 13 Jul 2000, David Hodgkinson wrote:
> > Doesn't FastCGI have exactly the same issues with dirty code? It's an
> > honest question; I'm not just being difficult.
>
> Almost. It runs in the main package as usual so at least you won't see
> screams about "...won't stay shared..." and such.
I always hated that problem. I guess wrapping your main:: in a while loop
for FCGI.pm does avoid this, although you have to modify your script,
unlike Registry or PerlRun.
Maybe we should try to make Registry/PerlRun smarter about the way they
wrap code, so that the subs don't get nested. On the face of it it
doesn't sound impossible, although undoubtedly there are certain ways to
defined named subs in perl that would be very hard to recognize correctly.
- Perrin
Re: PerlRun question
Posted by David Hodgkinson <da...@hodgkinson.org>.
Perrin Harkins <pe...@primenet.com> writes:
> Doesn't FastCGI have exactly the same issues with dirty code? It's an
> honest question; I'm not just being difficult.
Almost. It runs in the main package as usual so at least you won't see
screams about "...won't stay shared..." and such. You also have finer
control over how many of which scripts you run so one bad script won't
necessarily take everything with it.
--
Dave Hodgkinson, http://www.hodgkinson.org
Editor-in-chief, The Highway Star http://www.deep-purple.com
Apache, mod_perl, MySQL, Sybase hired gun for, well, hire
-----------------------------------------------------------------
Re: PerlRun question
Posted by Perrin Harkins <pe...@primenet.com>.
On 13 Jul 2000, David Hodgkinson wrote:
> Andrew Chen <ac...@cobaltgroup.com> writes:
>
> > Hi, I'm researching the nicest way to migrate our CGIs to running under
> > mod_perl, and although they are too dirty to run under Apache::Registry,
> > Apache::PerlRun works just fine.
>
> *snip*
>
> How dirty is dirty?
>
> If it's a case of assembling the globals into a big "use vars qw//"
> then that's OK. Boring but do-able.
>
>
> > Please help me with this! My internship depends on it! :) Thanks everyone.
>
> Looked at FastCGI? ;-)
Doesn't FastCGI have exactly the same issues with dirty code? It's an
honest question; I'm not just being difficult.
- Perrin
Re: PerlRun question
Posted by David Hodgkinson <da...@hodgkinson.org>.
Andrew Chen <ac...@cobaltgroup.com> writes:
> Hi, I'm researching the nicest way to migrate our CGIs to running under
> mod_perl, and although they are too dirty to run under Apache::Registry,
> Apache::PerlRun works just fine.
*snip*
How dirty is dirty?
If it's a case of assembling the globals into a big "use vars qw//"
then that's OK. Boring but do-able.
> Please help me with this! My internship depends on it! :) Thanks everyone.
Looked at FastCGI? ;-)
--
Dave Hodgkinson, http://www.hodgkinson.org
Editor-in-chief, The Highway Star http://www.deep-purple.com
Apache, mod_perl, MySQL, Sybase hired gun for, well, hire
-----------------------------------------------------------------
Re: PerlRun question
Posted by Andrew Chen <ac...@cobaltgroup.com>.
On Thu, 13 Jul 2000, Honza Pazdziora wrote:
> On Thu, Jul 13, 2000 at 01:54:28PM -0700, Andrew Chen wrote:
> >
> > That sounds like a pretty concrete solution. It seemed weird that there
> > wasn't an in-between solution to the issue.
>
> The reason probably is, that you really want to clean your code at
> the end. So all the big guys are either writing everything using
> Apache::Request, or cleaned up their *.pl's to run fine within
> Apache::Registry. You need such hackery only for the migration part,
> not for production code.
Yes, ultiimately we are looking to do that. Between the time that it takes
for us to set this up and for people to realize how much of a speed boost
there is (and thus dedicate resources to it) we need to come up with an
interim solution. Thus this these two hacky solutions have been thought
up. If you have any other ideas in terms of what another solution for the
migration should be, I'd love to hear it.
So from your first e-mail, I guess the idea of a module that would be
loaded at the end up the startup file that stores away all the information
up to that point so that the rest of the stuff loaded after then is
flushed-- you've never heard of anything that does something like that?
Thanks,
Andrew
Re: PerlRun question
Posted by Honza Pazdziora <ad...@informatics.muni.cz>.
On Thu, Jul 13, 2000 at 01:54:28PM -0700, Andrew Chen wrote:
>
> That sounds like a pretty concrete solution. It seemed weird that there
> wasn't an in-between solution to the issue.
The reason probably is, that you really want to clean your code at
the end. So all the big guys are either writing everything using
Apache::Request, or cleaned up their *.pl's to run fine within
Apache::Registry. You need such hackery only for the migration part,
not for production code.
--
------------------------------------------------------------------------
Honza Pazdziora | adelton@fi.muni.cz | http://www.fi.muni.cz/~adelton/
.project: Perl, DBI, Oracle, MySQL, auth. WWW servers, MTB, Spain.
Petition for a Software Patent Free Europe http://petition.eurolinux.org
------------------------------------------------------------------------
Re: PerlRun question
Posted by Andrew Chen <ac...@cobaltgroup.com>.
On Thu, 13 Jul 2000, Honza Pazdziora wrote:
> On Thu, Jul 13, 2000 at 11:51:14AM -0700, Andrew Chen wrote:
> >
> > The first one is that we have two types of files that are handled
> > differently, *.cgi (handled under PerlRun with PerlRunOnce On) and then
> > *.pr (handled under PerlRun with PerlRunOnce Off). The idea is that
> > everything runs under *.cgi in the beginning (which is the first step of
> > the migration), and then we slowly clean up files and put them into *.pr
> > files. The main problem is that because there's lots of references to
> > *.cgi everywhere, every file we cleaned up and renamed to *.pr would have
> > to have all of its referrers changed to do that (that's a lot of work).
>
> You could use the Trans stage and write a handler that would check
> that if it's a reference to *.cgi and that *.cgi doesn't exists but
> there is a *.pr file instead, the *.pr will be run with PerlRunOnce.
> Then you don't need to change anything in your links. I have it setup
> in similar thing and work just fine.
>
That makes sense, and we were thinking that we would probably have to
write a Apache module in order to have a solution. The issue is that the
entire situation is kind of hacky which is why we'd like to go with the
second migration strategy.
If it turns out the second strategy is unfeasible, I'd like to keep in
touch so that I might be able to look at some of your code. This project
would be my first Apache module.
> > The second strategy is to get mod_perl to compromise between the effects
> > of PerlRunOnce On and PerlRunOnce Off. Is there an easy for for PerlRun to
> > flush everything (including packages) that wasn't preloaded in the
> > startup.pl file? That would be a compromise between killing the child
> > everytime and keeping all the packages around.
>
> This is very good point. IMO what we might need is a module that would
> be run just at the end of the startup (or at child init), inspect what
> all modules are loaded, and store that information somewhere. Then
> within the PerlHandler (or perhaps even a bit sooner), everything
> instead of the packages (or generaly objects) that were noted to
> exist just whan the child started, would be cleaned, set to undef,
> deleted, whatever.
>
That sounds like a pretty concrete solution. It seemed weird that there
wasn't an in-between solution to the issue.
Does anyone have comments about this? It sounds good but how hard would
something like this be? If it's not too difficult it might be something we
could do in-house. Has anyone done something like this or are there
current solutions for this problem?
Thanks,
Andrew
Re: PerlRun question
Posted by Honza Pazdziora <ad...@informatics.muni.cz>.
On Thu, Jul 13, 2000 at 11:51:14AM -0700, Andrew Chen wrote:
>
> The first one is that we have two types of files that are handled
> differently, *.cgi (handled under PerlRun with PerlRunOnce On) and then
> *.pr (handled under PerlRun with PerlRunOnce Off). The idea is that
> everything runs under *.cgi in the beginning (which is the first step of
> the migration), and then we slowly clean up files and put them into *.pr
> files. The main problem is that because there's lots of references to
> *.cgi everywhere, every file we cleaned up and renamed to *.pr would have
> to have all of its referrers changed to do that (that's a lot of work).
You could use the Trans stage and write a handler that would check
that if it's a reference to *.cgi and that *.cgi doesn't exists but
there is a *.pr file instead, the *.pr will be run with PerlRunOnce.
Then you don't need to change anything in your links. I have it setup
in similar thing and work just fine.
> The second strategy is to get mod_perl to compromise between the effects
> of PerlRunOnce On and PerlRunOnce Off. Is there an easy for for PerlRun to
> flush everything (including packages) that wasn't preloaded in the
> startup.pl file? That would be a compromise between killing the child
> everytime and keeping all the packages around.
This is very good point. IMO what we might need is a module that would
be run just at the end of the startup (or at child init), inspect what
all modules are loaded, and store that information somewhere. Then
within the PerlHandler (or perhaps even a bit sooner), everything
instead of the packages (or generaly objects) that were noted to
exist just whan the child started, would be cleaned, set to undef,
deleted, whatever.
--
------------------------------------------------------------------------
Honza Pazdziora | adelton@fi.muni.cz | http://www.fi.muni.cz/~adelton/
.project: Perl, DBI, Oracle, MySQL, auth. WWW servers, MTB, Spain.
Petition for a Software Patent Free Europe http://petition.eurolinux.org
------------------------------------------------------------------------
Re: PerlRun question
Posted by Ken Williams <ke...@forum.swarthmore.edu>.
perrin@primenet.com (Perrin Harkins) wrote:
>On Mon, 17 Jul 2000, Andrew Chen wrote:
>
>> On Mon, 17 Jul 2000, Perrin Harkins wrote:
>>
>> > > I think it's trying to call a method for an object that doesn't
>> > > exist anymore. My guess is that I am keeping a certain variable
>> > > that keeps a list of the object in memory or something similar
>> > > that I should really be flushing. Because I'm protecting it, the
>> > > list doesn't get refreshed. Does anyone know the solution to this
>> > > problem?
>> >
>> > You may need to modify %INC. Try removing the modules that aren't
>> > in your "to keep" list from it at the same point where you clean
>> > put their namespaces. PerlRun does a variation of this too.
>>
>> I did what you suggested and I have it clearing out the proper
>> entries in %INC. The problem is that it still doesn't work! Even
>> though they don't exist in the hash, when a cgi needs a module it
>> still tries to call it from memory.
>>
>> Is there maybe another variable that I should be looking at?
>
>I'm running out of ideas. You could try changing your "use" statements
>to "require" and see if that helps. I thought PerlRun would cause
>these to be executed every time, but maybe not.
Changing to "require" should help. Remember that "use" is equivalent to
"require" and "import" in a BEGIN block (the BEGIN block is the
important part), so it will only happen once even if the same code is
run over and over.
Then again, something still puzzles me about this situation too, though
I can't put my finger on it. I'm not sure I understand the ins and outs
of what PerlRun does with BEGIN blocks, for instance.
------------------- -------------------
Ken Williams Last Bastion of Euclidity
ken@forum.swarthmore.edu The Math Forum
Re: PerlRun question [RESOLVED]
Posted by Perrin Harkins <pe...@primenet.com>.
On Thu, 20 Jul 2000, Andrew Chen wrote:
> Another mod_perl success :)
Congratulations! If you have a chance, you might want to write a brief
desccription for the Success Stories page at
http://perl.apache.org/stories/.
- Perrin
Re: PerlRun question [RESOLVED]
Posted by Andrew Chen <ac...@cobaltgroup.com>.
Perrin, Ken, Honza, and all others that helped:
The problem was actually that I wasn't clearing %INC properly after
flushing out all the dirty modules. After doing that everything started
working properly.
So anyway, I wrote an Perl script and installed it as an
PerlCleanupHandler. I stole code from the PerlRun source code so that,
instead of just flushing it's immediate variables, it actually actively
looks around into other packages and clears them out as well. Thus we are
flushing out some of the dirty modules that were causing us problems while
keeping the clean modules in memory. Basically we have the advantages of
PerlRun with PerlRunOnce Off without the headache of changing the existing
codebase (even though there is a little overhead with this cleanup
script).
The affect of this is that we have database pooling as well as a
significant performance boost (between 50%-200%) without having to change
a single line of code. We plan on slowly migrating all our code to add to
our "keep" list, which will increase performance even more.
Another mod_perl success :)
Anyway, thanks a lot-- this mailing list really did help a lot.
Andrew
Re: PerlRun question
Posted by Perrin Harkins <pe...@primenet.com>.
On Mon, 17 Jul 2000, Andrew Chen wrote:
> On Mon, 17 Jul 2000, Perrin Harkins wrote:
>
> > > I think it's trying to call a method for an object that doesn't exist
> > > anymore. My guess is that I am keeping a certain variable that keeps a
> > > list of the object in memory or something similar that I should really be
> > > flushing. Because I'm protecting it, the list doesn't get refreshed. Does
> > > anyone know the solution to this problem?
> >
> > You may need to modify %INC. Try removing the modules that aren't in your
> > "to keep" list from it at the same point where you clean put their
> > namespaces. PerlRun does a variation of this too.
>
> I did what you suggested and I have it clearing out the proper entries in
> %INC. The problem is that it still doesn't work! Even though they don't
> exist in the hash, when a cgi needs a module it still tries to call it
> from memory.
>
> Is there maybe another variable that I should be looking at?
I'm running out of ideas. You could try changing your "use" statements to
"require" and see if that helps. I thought PerlRun would cause these to
be executed every time, but maybe not.
- Perrin
Re: PerlRun question
Posted by Andrew Chen <ac...@cobaltgroup.com>.
On Mon, 17 Jul 2000, Perrin Harkins wrote:
> > I think it's trying to call a method for an object that doesn't exist
> > anymore. My guess is that I am keeping a certain variable that keeps a
> > list of the object in memory or something similar that I should really be
> > flushing. Because I'm protecting it, the list doesn't get refreshed. Does
> > anyone know the solution to this problem?
>
> You may need to modify %INC. Try removing the modules that aren't in your
> "to keep" list from it at the same point where you clean put their
> namespaces. PerlRun does a variation of this too.
I did what you suggested and I have it clearing out the proper entries in
%INC. The problem is that it still doesn't work! Even though they don't
exist in the hash, when a cgi needs a module it still tries to call it
from memory.
Is there maybe another variable that I should be looking at?
Andrew
Re: PerlRun question
Posted by Perrin Harkins <pe...@primenet.com>.
On Mon, 17 Jul 2000, Andrew Chen wrote:
> In the to-keep list, there's the obvious stuff (database and other base
> libraries) but also I ran a blank script and kept all the variables
> brought up in that blank list (Apache::*, &c.). This way I'm not clearing
> stuff that I'm supposed to.
I'd suggest that you only clear things in your own code, and avoid
clearing anything in code from CPAN modules, Apache:: or otherwise.
> One issue that I have at this point is that although the script runs and
> seems to do what it's supposed to do, it breaks stuff. If I go through
> these steps
>
> 1) Start httpd
> 2) Run flushvars.cgi (nothing flushed, because it's clean)
> 3) Go to a cgi that loads a bunch of modules
> 4) Run flushvars.cgi (a bunch of stuff is flushed-- just the modules that
> were loaded in step 3)
> 5) Go to a cgi that uses a lot of the modules that were flushed in step 4
> 6) It breaks
>
> I think it's trying to call a method for an object that doesn't exist
> anymore. My guess is that I am keeping a certain variable that keeps a
> list of the object in memory or something similar that I should really be
> flushing. Because I'm protecting it, the list doesn't get refreshed. Does
> anyone know the solution to this problem?
You may need to modify %INC. Try removing the modules that aren't in your
"to keep" list from it at the same point where you clean put their
namespaces. PerlRun does a variation of this too.
- Perrin
Re: PerlRun question
Posted by Andrew Chen <ac...@cobaltgroup.com>.
Thanks for the idea. I went ahead and implemented this, and am very close.
I currently have a script looks at all the variables and undefines all of
them with a few exceptions (code copied from PerlRun.pm of mod_perl
source). The way that the exceptions are managed is that I keep a list of
the variables that I want to keep, and clear the variables that aren't on
the list out.
In the to-keep list, there's the obvious stuff (database and other base
libraries) but also I ran a blank script and kept all the variables
brought up in that blank list (Apache::*, &c.). This way I'm not clearing
stuff that I'm supposed to.
One issue that I have at this point is that although the script runs and
seems to do what it's supposed to do, it breaks stuff. If I go through
these steps
1) Start httpd
2) Run flushvars.cgi (nothing flushed, because it's clean)
3) Go to a cgi that loads a bunch of modules
4) Run flushvars.cgi (a bunch of stuff is flushed-- just the modules that
were loaded in step 3)
5) Go to a cgi that uses a lot of the modules that were flushed in step 4
6) It breaks
I think it's trying to call a method for an object that doesn't exist
anymore. My guess is that I am keeping a certain variable that keeps a
list of the object in memory or something similar that I should really be
flushing. Because I'm protecting it, the list doesn't get refreshed. Does
anyone know the solution to this problem?
Thanks for your time-- this is really turning out a lot better than I had
initially hoped. Cc:: me on the reply because I am not subscribed to the
mod_perl mailing list.
Andrew Chen
Intern, Architecture
achen@cobaltgroup.com
206-219-8445
The Cobalt Group, Inc.
On Fri, 14 Jul 2000, Perrin Harkins wrote:
> On Fri, 14 Jul 2000, Andrew Chen wrote:
> > > You can actually do this from one place, iterating through a list of
> > > namespaces to flush. Look at the code in
> > > Apache::PerlRun::flush_namepsace. It's pretty easy.
> >
> > We would still have to add code to every module, correct? Even though
> > there could be a central variable flushing module, all the other modules
> > would still want to call it. So although we may not be including the
> > flush_namespace code in every module, we will at least need to call them.
>
> No, you just need to have one module that contains a list of the packages
> to flush and the code to do it, and then install that as a
> PerlCleanupHandler so it will automatically run after every request.
>
> - Perrin
>
Re: PerlRun question
Posted by Perrin Harkins <pe...@primenet.com>.
On Fri, 14 Jul 2000, Andrew Chen wrote:
> > You can actually do this from one place, iterating through a list of
> > namespaces to flush. Look at the code in
> > Apache::PerlRun::flush_namepsace. It's pretty easy.
>
> We would still have to add code to every module, correct? Even though
> there could be a central variable flushing module, all the other modules
> would still want to call it. So although we may not be including the
> flush_namespace code in every module, we will at least need to call them.
No, you just need to have one module that contains a list of the packages
to flush and the code to do it, and then install that as a
PerlCleanupHandler so it will automatically run after every request.
- Perrin
Re: PerlRun question
Posted by Andrew Chen <ac...@cobaltgroup.com>.
On Thu, 13 Jul 2000, Perrin Harkins wrote:
> On Thu, 13 Jul 2000, Andrew Chen wrote:
> > PerlRun already flushes everything, but from my understanding of it,
> > with PerlRunOnce Off mod_perl won't flush the packages that were loaded by
> > the CGIs.
>
> What makes you think they need to be flushed? Are they things you wrote
> in-house that didn't follow the normal module conventions of package names
> and lexical variables? If not, they shouldn't be a problem.
A lot of the code was written without really thinking about potential
future moves such as mod_perl. Because of this a lot of variables get used
without getting initialized-- that kind of thing. We've already observed
some little issues with the code that can be fixed with adding lines to
initialize the variables, but that is easier said than done with hundreds
(or more) of files.
>
> > Again, for the reason offered in the first paragraph, we don't want to be
> > cutting and pasting code to flush variables in *every* module we have,
> > because we really have a lot.
>
> You can actually do this from one place, iterating through a list of
> namespaces to flush. Look at the code in
> Apache::PerlRun::flush_namepsace. It's pretty easy.
We would still have to add code to every module, correct? Even though
there could be a central variable flushing module, all the other modules
would still want to call it. So although we may not be including the
flush_namespace code in every module, we will at least need to call them.
I look forward to your reply. Thanks for your input on this...
Andrew
Re: PerlRun question
Posted by Perrin Harkins <pe...@primenet.com>.
On Thu, 13 Jul 2000, Andrew Chen wrote:
> PerlRun already flushes everything, but from my understanding of it,
> with PerlRunOnce Off mod_perl won't flush the packages that were loaded by
> the CGIs.
What makes you think they need to be flushed? Are they things you wrote
in-house that didn't follow the normal module conventions of package names
and lexical variables? If not, they shouldn't be a problem.
> Again, for the reason offered in the first paragraph, we don't want to be
> cutting and pasting code to flush variables in *every* module we have,
> because we really have a lot.
You can actually do this from one place, iterating through a list of
namespaces to flush. Look at the code in
Apache::PerlRun::flush_namepsace. It's pretty easy.
- Perrin
Re: PerlRun question
Posted by Andrew Chen <ac...@cobaltgroup.com>.
We basically want to run our scripts under PerlRun with PerlRunOnce Off.
The issue is that because we are a little short handed, and we have many
many many CGIs, any process of cleaning stuff up (maybe 1% has use strict)
would be a long and lengthy one.
PerlRun already flushes everything, but from my understanding of it,
with PerlRunOnce Off mod_perl won't flush the packages that were loaded by
the CGIs. It works fine with PerlRunOnce On, but we want the performance
boost offered by turning it off.
Again, for the reason offered in the first paragraph, we don't want to be
cutting and pasting code to flush variables in *every* module we have,
because we really have a lot.
Because of this we are trying to get the best speed and then distribute
the code maintenance over a long period of time.
Andrew Chen
Intern, Architecture
achen@cobaltgroup.com
206-219-8445
The Cobalt Group, Inc.
On Thu, 13 Jul 2000, Perrin Harkins wrote:
> On Thu, 13 Jul 2000, Andrew Chen wrote:
>
> > The second strategy is to get mod_perl to compromise between the effects
> > of PerlRunOnce On and PerlRunOnce Off. Is there an easy for for PerlRun to
> > flush everything (including packages) that wasn't preloaded in the
> > startup.pl file? That would be a compromise between killing the child
> > everytime and keeping all the packages around.
>
> It already flushes everything defined within your script. If you want to
> flush things defined in other packages as well, you could copy the (fairly
> simple) code from PerlRun that does this and apply it to other packages.
>
> Before you do this though, consider whether or not you really need to. If
> you're using things from CPAN or that you've written as actual modules
> with their own packages and "use strict" on, you shouldn't need to flush
> them.
>
> - Perrin
>
Re: PerlRun question
Posted by Perrin Harkins <pe...@primenet.com>.
On Thu, 13 Jul 2000, Andrew Chen wrote:
> The second strategy is to get mod_perl to compromise between the effects
> of PerlRunOnce On and PerlRunOnce Off. Is there an easy for for PerlRun to
> flush everything (including packages) that wasn't preloaded in the
> startup.pl file? That would be a compromise between killing the child
> everytime and keeping all the packages around.
It already flushes everything defined within your script. If you want to
flush things defined in other packages as well, you could copy the (fairly
simple) code from PerlRun that does this and apply it to other packages.
Before you do this though, consider whether or not you really need to. If
you're using things from CPAN or that you've written as actual modules
with their own packages and "use strict" on, you shouldn't need to flush
them.
- Perrin