Module caching

2003-08-01 Thread Scott
Hello all,
I am working on a large modperl app, and one of the features of this is a
plugin system that allows others to write and install modules. Everything is
good as far as this goes, but the problem is updateing/deleting modules. It
seems as though the code is cached until an apache restart (i.e code changes
don't take effect, version numbers don't change). Is there a way to flush
the INC hash of all the children programmatically, without a restart? I have
looked at Apache::Reload and Apache::StatINC and tried to replicate the
code, but it doesn't seem to be working.

Thanks,
Scott



Re: Module caching

2003-08-01 Thread Perrin Harkins
On Fri, 2003-08-01 at 13:42, Scott wrote:
 I have
 looked at Apache::Reload and Apache::StatINC

And what was wrong with them?  You should know that there is no perfect
way to reload a Perl module.  It just isn't a feature of the language. 
Those two modules come as close as you can get without actually starting
a new interpreter, but it is still possible for some code (especially
code using closures) to interact badly with them.

- Perrin


Re: Module caching

2003-08-01 Thread Marcin Kasperski
Scott [EMAIL PROTECTED] writes:

 Hello all,
 I am working on a large modperl app, and one of the features of this is a
 plugin system that allows others to write and install modules. Everything is
 good as far as this goes, but the problem is updateing/deleting modules. It
 seems as though the code is cached until an apache restart (i.e code changes
 don't take effect, version numbers don't change). Is there a way to flush
 the INC hash of all the children programmatically, without a restart? I have
 looked at Apache::Reload and Apache::StatINC and tried to replicate the
 code, but it doesn't seem to be working.

The best thing I happened to meet here:
- apache compiled with mod_perl as DSO (for instance debian linux version)
- graceful restart which is invisible for the clients but reloads perl
  interpreter when mod_perl is DSO