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
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 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 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
> (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 -
