Is this being done in the Apache parent process or only in the child processes?
If in the Apache parent process, you would still have to call Tcl_Finalize() at some point wouldn't you to ensure that all memory is reclaimed? One of the flaws early on in mod_python was that it didn't destroy the Python interpreter. When an Apache restart was done, mod_python and the Python library would be unloaded from memory. When the in process startup was done after rereading the configuration Apache would load them again. Because it was reloaded it was a completely clean set of static variables holding interpreter state and so interpreter had to be reinitialised. In other words, the unload/load that happens for modules on a restart meant that it leaked memory into the Apache parent process, resulting in the parent process continually growing over time when restarts were done. Even though mod_python was fixed and destroying the interpreter done. Python itself still didn't always clean up memory completely and left some static data in place on basis that if interpreter reinitialised in same process, would just reuse that to avoid creating it again. Unfortunately the unload/load cycle of modules still meant that memory leaked and so mod_python as a result still leaks memory into the Apache parent process. In the end in mod_wsgi, because of Python leaking memory in this way, had to defer initialisation of interpreter until child processes were forked, as simply wasn't possible to get Python to change what it did. Graham On 6 February 2013 10:11, Mikhail T. <mi+t...@aldan.algebra.com> wrote: > On 05.02.2013 18:01, William A. Rowe Jr. wrote: > > What if both attempt to register an identical apr_optional_fn for > tcl_destroy. That way you will never have both optional functions > called. > > My plan was for each of the modules to skip the destruction, if the OTHER > module is registered to run clean-up AFTER it. > > This way the last module in the list will always run the destructor. > > FWIW I would call that function as a destructor of the process_pool, > which you can find by walking the config pool's parents. > > That's an idea... But, I think, I found a Tcl-specific solution for this > particular problem -- instead of calling Tcl_Finalize(), which ruins libtcl > for everyone in the same process, mod_rivet should simply delete the > Tcl-interpreter it created (websh does limit itself to exactly that > already). > > Let's see, what mod_rivet maintainers have to say ( > https://issues.apache.org/bugzilla/attachment.cgi?id=29923&action=diff). > > But this was a very educating thread nonetheless. Thank you, everyone. > Yours, > > -mi > >
