quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Robbins" <je...@livedata.com>
Subject Re: MODPYTHON-195
Date Tue, 07 Nov 2006 11:51:53 GMT

The problem on Win32 is that (I believe) we never want to initialize Python 
in the persistent parent process.  All the web action is in the child 
process which is long-lived and it is this child process that maintains the 
thread pool which services web requests.

The parent process as far as I can tell sits there to support restarting the 
child process and support the Win32 Service Control Manager (SCM) which has 
a protocol for how a process must respond to certain messages in order to be 
a service on Win32.

I do not know how to use flags alone to distinguish the two processes.  The 
code I put in is not trying to restrict a call to python_init() to only 
happen once in the parent process.  It is preventing python_init() from 
initializing Python in the parent process.

I hope this clarifies things somewhat.

I want to note here that mpm_winnt.c line 1108 looks like this:

/* AP_PARENT_PID is only valid in the child */
pid = getenv("AP_PARENT_PID");
if (pid)
/* This is the child */

This environmental is how it knows to run certain code only in the child 

In summary,

if we do not want to run python_init() in the special Win32 parent process, 
we need a way to distinguish this parent process from the child process in 
which we DO want to run python_init().   The code which maintains this dual 
process architecture (undoubtedly in support of the Win32 service 
architecture) uses an environmental that it purposefull creates and injects 
into the child process "AP_PARENT_PID".  I don't see how we can do better 
than use this same distinguishing characterisic to know not to run 
python_init() in the parent process.

----- Original Message ----- 
From: "Graham Dumpleton" <grahamd@dscpl.com.au>
To: "Jeff Robbins" <jeffr@livedata.com>
Cc: "python-dev list" <python-dev@httpd.apache.org>
Sent: Tuesday, November 07, 2006 06:02
Subject: Re: MODPYTHON-195

> 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

View raw message