Re: Results of calling perl_shutdown in mp_dso_unload
On Fri, 21 Jan 2000, Daniel Jacobowitz wrote: (with appropriate changes to unload DSOs after shutting down perl, of course). I still get memory leakage - that's not terribly surprising - but it is much less. It's on the order of about 24K/restart and is probably the fault of some module - my guts would be DBD::Pg. I'll play around with that later. It's small enough to show that the idea is workable. Restarts are also a bit slower, unsurprisingly - there's a lot more to do. right, that's one of the reasons restarts are a noop for mod_perl by default (not including dso-magic) Then we have the fact that this currently removes PerlRestartHandler functionality and goes far beyond PerlFreshRestart. Those are a big issue - those will HAVE to work differently depending on whether or not mod_perl is a DSO. If not, they can continue to work as before, but if it is they will never be invoked. I'll clean up the patch and fire it off later this weekend, if Doug doesn't get a chance to look at it before then. Doug is slowly crawling back from the death flu :-/ I'm think about releasing 1.22 as it stands in the cvs tree, since it's so long overdue, and bang out the dso issues from there. as much as I want to cure the dso problems, I don't want to introduce new problems the currently stable static configuration.
Re: Results of calling perl_shutdown in mp_dso_unload
On Wed, Jan 26, 2000 at 08:13:41PM -0800, Doug MacEachern wrote: right, that's one of the reasons restarts are a noop for mod_perl by default (not including dso-magic) Makes sense. Here's a question - an apache patch should be able to mark the module as not-to-unload (although since it should be not-to-unload-unless-removed-from-config it would be a bit more complicated than that - still not impossible). But is that worthwhile or should we just adjust to being unloaded if built as DSO? Then we have the fact that this currently removes PerlRestartHandler functionality and goes far beyond PerlFreshRestart. Those are a big issue - those will HAVE to work differently depending on whether or not mod_perl is a DSO. If not, they can continue to work as before, but if it is they will never be invoked. I'll clean up the patch and fire it off later this weekend, if Doug doesn't get a chance to look at it before then. Doug is slowly crawling back from the death flu :-/ I'm think about releasing 1.22 as it stands in the cvs tree, since it's so long overdue, and bang out the dso issues from there. as much as I want to cure the dso problems, I don't want to introduce new problems the currently stable static configuration. Understood - good idea. Which reminds me - the CVS instructions linked from perl.apache.org no longer work. Is there a public CVS archive still? Where did it move? Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/
Re: Results of calling perl_shutdown in mp_dso_unload
On Wed, 26 Jan 2000, Daniel Jacobowitz wrote: Here's a question - an apache patch should be able to mark the module as not-to-unload (although since it should be not-to-unload-unless-removed-from-config it would be a bit more complicated than that - still not impossible). But is that worthwhile or should we just adjust to being unloaded if built as DSO? I think both options would be nice to have. Which reminds me - the CVS instructions linked from perl.apache.org no longer work. Is there a public CVS archive still? Where did it move? things have changed recently, here's a snippet from the latest mod_perl_cvs.pod: =item anoncvs To checkout a fresh copy from anoncvs use cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" login with the password "anoncvs". cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" co modperl For a basic introduction to anoncvs see http://dev.apache.org/anoncvs.txt
Re: Results of calling perl_shutdown in mp_dso_unload
On Jan 26, Doug MacEachern wrote: =item anoncvs To checkout a fresh copy from anoncvs use cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" login with the password "anoncvs". cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" co modperl Both of those should have another colon before the pserver. Like: cvs -d ":pserver:[EMAIL PROTECTED]:/home/cvspublic" login Jim
RE: Results of calling perl_shutdown in mp_dso_unload
(with appropriate changes to unload DSOs after shutting down perl, of course). I still get memory leakage - that's not terribly surprising - but it is much less. It's on the order of about 24K/restart and is probably the fault of some module - my guts would be DBD::Pg. I'll play around with that later. It's small enough to show that the idea is workable. Sounds good :-) Restarts are also a bit slower, unsurprisingly - there's a lot more to do. Then we have the fact that this currently removes PerlRestartHandler functionality and goes far beyond PerlFreshRestart. Those are a big issue - those will HAVE to work differently depending on whether or not mod_perl is a DSO. If not, they can continue to work as before, but if it is they will never be invoked. Maybe we could test some variables inside Apache to determinate if it is a restart or real start and invoke the PerlRestartHandler accordingly, also it will still make a difference, because in the DSO situation, we start with a fresh Perl. I'll clean up the patch and fire it off later this weekend, if Doug doesn't get a chance to look at it before then. Great! Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
