Apache Mod-Python - Re: MODPYTHON-195

This is Interesting: Free IT Magazines  
Home > Archive > Apache Mod-Python > November 2006 > Re: MODPYTHON-195





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Re: MODPYTHON-195
Jeff Robbins

2006-11-08, 7:12 am

Graham,

You placed the fix in a better spot than I did. I had placed it after the
apr_pool_userdata stuff due to not understanding what that was all about.
It makes better sense to simply test and exit the python_init() routine as
quickly as possible in the Win32 parent process. Your comment is good, too.
I will test your version and confirm.

Thanks!

Jeff
----- 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: Wednesday, November 08, 2006 05:38
Subject: Re: MODPYTHON-195


>
> On 07/11/2006, at 10:51 PM, Jeff Robbins wrote:
>
>
> FWIW, in UNIX the initialisation of Python in the parent process is a
> good thing
> as it means it is only done once no matter how many child processes there
> are. This is because child processes are created as a fork of the parent
> process
> and so they inherit the already initialised Python interpreter, thereby
> meaning
> initialisation of the child process is quicker.
>
> Since Win32 doesn't have an equivalent of fork, when the child process
> is created the full Python initialisation is done anyway. Thus avoiding
> the
> initialisation of Python in the parent is probably reasonable.
>
>
> As it stands I just may have to take you word on this as I don't have
> first hand
> access to Win32 platform (and don't want to) to experiment. The
> AP_PARENT_PID
> environment variable is at least present in all Apache 2.0 and 2.2
> versions that
> we support, so at least okay for a while if we rely on that. In the
> future, if Apache
> changes this, we will just need to accommodate any new/official way of
> determining
> it.
>
> Anyway, is the following what you are expecting and is it placed where
> you expect
> it within the python_init() function?
>
> static int initialized = 0;
>
> #ifdef WIN32
> /* No need to run python_init() in Win32 parent processes as
> * the lack of fork on Win32 means we get no benefit as far as
> * inheriting a preinitialized Python interpreter. Further,
> * upon a restart on Win32 platform the python_init() function
> * will be called again in the parent process but without some
> * resources allocated by the previous call having being
> * released properly, resulting in memory and Win32 resource
> * leaks.
> */
> if (!getenv("AP_PARENT_PID"))
> return OK;
> #endif /* WIN32 */
>
> apr_pool_userdata_get(&data, userdata_key, s->process->pool);
> if (!data) {
> apr_pool_userdata_set((const void *)1, userdata_key,
> apr_pool_cleanup_null, s->process->pool);
> return OK;
> }
>
>
>
> Graham
>



Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com