Re: Results of calling perl_shutdown in mp_dso_unload

2000-01-26 Thread Doug MacEachern
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

Re: Results of calling perl_shutdown in mp_dso_unload

2000-01-26 Thread Daniel Jacobowitz
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

Re: Results of calling perl_shutdown in mp_dso_unload

2000-01-26 Thread Doug MacEachern
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

Re: Results of calling perl_shutdown in mp_dso_unload

2000-01-26 Thread Jim Winstead
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

RE: Results of calling perl_shutdown in mp_dso_unload

2000-01-21 Thread Gerald Richter
(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