On 04/11/2006, at 12:34 PM, Jeff Robbins wrote:

> Graham,
>
> I haven't had any new ideas about this problem.  It is clear that
> on Windows, mod_python is initialized both in a parent process and
> more usefully in the child process that spins up the threads that
> service client requests.  The parent process is long-lived and the
> standard hack to wait for the second call to the
> ap_hook_post_config is useless because each "restart" of apache is
> yet another call (third, fourth, fifth, etc...) and each time
> there's a leak of one handle.
>
>
> The fix I tested seems reasonable.  I know it is dependent on
> mpm_winnt.c, but, after all, that file is the file responsible for
> the dual process architecture on windows to begin with.  And the
> fix has an #ifdef win32 so it won't hurt linux users.
>
> I'd like you to consider folding it in.  I think it is better than
> having a leak (along with spurious Python initialization) on windows.

Jeff, can you see if you can come up with a test based on
'initialized' and
'child_init_pool' as I note in:

http://issues.apache.org/jira/browse/MODPYTHON-195

If it is only in the parent process you need to skip subsequent
calls, perhaps:

if (child_init_pool == 0 && initialized != 0)
return OK;

Will have to think about how this may screw up old versions of Mac OS X
though which is why initialized was added in the first place.

You might include in your debug a call to Py_IsInitialized() so it
can be
determined if Python thinks it is already initialised. Since your
fiddle is
working, I'd say it probably is.

Also see if main_server is set and not zero as well and whether its
value
is different to 's' passed as argument to function. Whether it is the
same
or not may dictate where in function the check to bail out of
function needs
to be. It may have to go just before the global config and mutexes are
created.

Graham

[ Post a follow-up to this message ]