[mod_python] [patch] make autoreload more useful

Dustin Mitchell dustin at ywlcs.org
Wed May 29 19:53:12 EST 2002

On Thu, May 30, 2002 at 10:38:51AM +1000, Martin Pool wrote:
> > Even with gc, if there are any dangling references into one of the old
> > modules (an atexit function? somewhere the Python standard libraries cache a
> > reference?) then you're going to have a bloated httpd.
> Using atexit functions within mod_python is pretty pointless, but your
> general point about references held by system modules is correct.
> If my code bloated that easily because of reloading modules then I
> would be somewhat worried that something would cause it to happen
> during production, and I'd feel I ought to investigate what was going
> wrong.
> You can always turn down MaxRequestsPerChild, or indeed turn off
> autoreload.

Ah!  I had forgotten MaxRequestsPerChild, which lets Apache take care of
counting reloads, so a Python reloader need not worry about it.

> I guess in general I believe that in development mode (as opposed to
> release), correctness and developer productivity is more important
> than performance.

I don't disagree.  You'll note that I'm arguing for features on the basis of
developer convenience at minimal (but not zer) performance cost, which
translates into developer productivity.

> In deployment mode, there shouldn't be any bloat because the .py files
> won't change.  The cost is just stat'ing them each time, which is a
> slight cost but not terrible.

And the cost will be zero, if AutoReload is turned off :-)

> As far as I can see, the only non-bogus use of persistence is
> opportunistic caching.  Modules have to cope with losing their
> persistent state because (a) requests are unpredictably spread across
> Apache instances; (b) Apache can kill and restart children; (c)
> relying on it is overly fragile; and (d) without a working reload
> mechanism, the programmer will be completely restarting Apache at
> intervals anyhow.

True, but there are valid reasons to want to test and develop such
opportunistic caching mechanisms (since anything opportunistic is by at least
a little bit nondeterministic, it probably needs the most testing).  There
are also performance implications, as I detailed in my other reply in this
thread (<20020530004544.GF2519 at eleanor.internal.ywlcs.org>).  As I said a few
paragraphs earlier, developer convenience with minimal impact on

BTW: I assume you're not implying that opportunistic caching is overly
fragile!  It's a great technique!  Relying on not being reloaded, however, is
obviously stupid, since the Apache API *will* reload you :-)

I don't actually care too much about this whole thing; just putting in my
$0.02.  If y'all are really opposed to it, don't put it in.  I'll still love
you, and you can keep the pennies. :-)



  Dustin Mitchell
  dustin at ywlcs.org

More information about the Mod_python mailing list