Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D8F56E2AD for ; Tue, 5 Feb 2013 23:25:43 +0000 (UTC) Received: (qmail 83767 invoked by uid 500); 5 Feb 2013 23:25:43 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 83712 invoked by uid 500); 5 Feb 2013 23:25:43 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 83702 invoked by uid 99); 5 Feb 2013 23:25:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Feb 2013 23:25:43 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of graham.dumpleton@gmail.com designates 74.125.82.44 as permitted sender) Received: from [74.125.82.44] (HELO mail-wg0-f44.google.com) (74.125.82.44) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Feb 2013 23:25:37 +0000 Received: by mail-wg0-f44.google.com with SMTP id dr12so613632wgb.11 for ; Tue, 05 Feb 2013 15:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=TjifZkuaxXnHv5JYu4bG9zCqfe+SMKHQazRhMfVf81M=; b=JK2ceaWJuzTD+ACZ3SATECnUc2/F7lurzXG6p7cjY2S+fBEsVWq9dktVikaItxW3jx xPRz4OfkaR04wBkSz4xUL69nxio3W8123PYOBZv4vBL5AaLBbC8tN6XXJGLNzUMd+5Kn Mm/uiO2BSwN0uta9kRAdAeW2CGN68BUNtsqRnXWyIPrjEGN5pm83EO51R7ZDZ17qQAYO SHA2u5VmJL5wFDswIImRfrsy/ou4k7/7AK+JfDLmkGj3tA76mdRHx1QG0yVfd835db/m vqlyBSQCcdzbYZGyCNWcDi52/m+gFaw84omT5ncJyXY4mFqN2HguZVtsPN6F1Ig2s/AF relw== MIME-Version: 1.0 X-Received: by 10.180.108.3 with SMTP id hg3mr898426wib.33.1360106716625; Tue, 05 Feb 2013 15:25:16 -0800 (PST) Sender: graham.dumpleton@gmail.com Received: by 10.216.48.15 with HTTP; Tue, 5 Feb 2013 15:25:16 -0800 (PST) In-Reply-To: <51119188.6070600@aldan.algebra.com> References: <511173CD.90600@aldan.algebra.com> <20130205213730.4550c564@baldur> <51117E18.5040103@aldan.algebra.com> <20130205170151.4c92d2c9@hub> <51119188.6070600@aldan.algebra.com> Date: Wed, 6 Feb 2013 10:25:16 +1100 X-Google-Sender-Auth: VKTAgH87acZ_Q1vebj75S-cScyk Message-ID: Subject: Re: Can a module find out, whether another module is present? From: Graham Dumpleton To: "dev@httpd.apache.org" Content-Type: multipart/alternative; boundary=e89a8f3ba6e3b379fd04d50285d0 X-Virus-Checked: Checked by ClamAV on apache.org --e89a8f3ba6e3b379fd04d50285d0 Content-Type: text/plain; charset=UTF-8 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. 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 > > --e89a8f3ba6e3b379fd04d50285d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is this being done in the Apache parent process or only in the= child processes?

If in the Apache parent process, you w= ould still have to call=C2=A0Tcl_Finalize() at some point wouldn't you to ensure that = all memory is reclaimed?

One of t= he flaws early on in mod_python was that it didn't destroy the Python i= nterpreter. When an Apache restart was done, mod_python and the Python libr= ary would be unloaded from memory. When the in process startup was done aft= er rereading the configuration Apache would load them again. Because it was= reloaded it was a completely clean set of static variables holding interpr= eter state and so interpreter had to be reinitialised.

=
In other words, the unload/load that happens for modules on a restart me= ant that it leaked memory into the Apache parent process, resulting in the = parent process continually growing over time when restarts were done.

Eve= n though mod_python was fixed and destroying the interpreter done. Python i= tself still didn't always clean up memory completely and left some stat= ic data in place on basis that if interpreter reinitialised in same process= , would just reuse that to avoid creating it again. Unfortunately the unloa= d/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 d= efer initialisation of interpreter until child processes were forked, as si= mply wasn't possible to get Python to change what it did.

Gra= ham


On 6 February 2013 10:11, Mikhail T. <mi+thun@aldan.algebra.com> wrote:
=20 =20 =20
On 05.02.2013 18:01, William A. Rowe Jr. wrote:
What if both attempt to register an identical apr_optional_fn fo=
r
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_p=
ool,
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/attac= hment.cgi?id=3D29923&action=3Ddiff).

But this was a very educating thread nonetheless. Thank you, everyone. Yours,
-mi

--e89a8f3ba6e3b379fd04d50285d0--