Commented: (MODPYTHON-77) The multiple interpreter concept of mod_python is broken for
Web Server forum
Back To The Forum Home!Search!Private Messaging System

Web Server Talk Web Server Talk > Web Servers reviews > Apache Server configuration support > Apache Mod-Python > Commented: (MODPYTHON-77) The multiple interpreter concept of mod_python is broken for




  Last Thread   Next Thread Next
  Show Printable Version Email this Page Subscribe to this Thread      Post New Thread    Post A Reply      

    Commented: (MODPYTHON-77) The multiple interpreter concept of mod_python is broken for  
Graham Dumpleton (JIRA)


View Ip Address Report This Message To A Moderator Edit/Delete Message


 
11-05-05 07:45 AM

[ http://issues.apache.org/jira/brows...2356
842 ]

Graham Dumpleton commented on MODPYTHON-77:
-------------------------------------------

Sorry, forgot to mention that my patch is in attachment "grahamd_20051105.ta
r.gz".

> The multiple interpreter concept of mod_python is broken for Python extens
ion modules since Python 2.3
> --------------------------------------------------------------------------
----------------------------
>
>          Key: MODPYTHON-77
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-77
>      Project: mod_python
>         Type: Bug
>   Components: core
>     Versions: 3.1.4
>  Environment: Python >= 2.3
>     Reporter: Boyan Boyadjiev
>  Attachments: diff.txt, diff2.txt, diff3.txt, gil_test.c, gilstate.tar.gz,
 grahamd_20051105.tar.gz, mod_python.c, mod_python.c.diff, mod_python.h.diff
, src.zip
>
> The multiple interpreter concept of mod_python is broken for Python extens
ion modules since Python 2.3 because of the PEP 311 (Simplified Global Inter
preter Lock Acquisition for Extensions):
> ...
> Limitations and Exclusions
>     This proposal identifies a solution for extension authors with
>     complex multi-threaded requirements, but that only require a
>     single "PyInterpreterState".  There is no attempt to cater for
>     extensions that require multiple interpreter states.  At the time
>     of writing, no extension has been identified that requires
>     multiple PyInterpreterStates, and indeed it is not clear if that
>     facility works correctly in Python itself.
> ...
> For mod_python this means, that complex Python extensions won't work any more with
 Python >= 2.3, because they are supposed to work only with the first interpreter st
ate initialized for the current process (a problem we experienced). The first interp
ret
er state is not used by mod_python after the python_init is called.
> One solution, which works fine for me, is to save the first interpreter st
ate into the "interpreters" dictionary in the function python_init (MAIN_INT
ERPRETER is used as a key):
> static int python_init(apr_pool_t *p, apr_pool_t *ptemp,
>                        apr_pool_t *plog, server_rec *s)
> {
>     ...
>     /* initialize global Python interpreter if necessary */
>     if (! Py_IsInitialized())
>     {
>         /* initialze the interpreter */
>         Py_Initialize();
> #ifdef WITH_THREAD
>         /* create and acquire the interpreter lock */
>         PyEval_InitThreads();
> #endif
>         /* create the obCallBack dictionary */
>         interpreters = PyDict_New();
>         if (! interpreters) {
>             ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0, s,
>                          "python_init: PyDict_New() failed! No more memory
?");
>             exit(1);
>         }
>         {
>             /*
>             Workaround PEP 311 - Simplified Global Interpreter Lock Acquis
ition for Extensions
>             BEGIN
>             */
>             PyObject *p = 0;
>             interpreterdata * idata = (interpreterdata *)malloc(sizeof(int
erpreterdata));
>             PyThreadState* currentThreadState = PyThreadState_Get();
>             PyInterpreterState *istate = currentThreadState->interp;
>             idata->istate = istate;
>             /* obcallback will be created on first use */
>             idata->obcallback = NULL;
>             p = PyCObject_FromVoidPtr((void ) idata, NULL); /*p->refcout =
 1*/
>             PyDict_SetItemString(interpreters, MAIN_INTERPRETER, p); /*p->
refcout = 2*/
>             Py_DECREF(p); /*p->refcout = 1*/
>             /*
>             END
>             Workaround PEP 311 - Simplified Global Interpreter Lock Acquis
ition for Extensions
>             */
>         }
>         /* Release the thread state because we will never use
>          * the main interpreter, only sub interpreters created later. */
>         PyThreadState_Swap(NULL);
> #ifdef WITH_THREAD
>         /* release the lock; now other threads can run */
>         PyEval_ReleaseLock();
> #endif
>     }
>     return OK;
> }
> Another change I've made in the attached file is to Py_DECREF(p) in get_interprete
r, which will remove leaky reference to the PyCObject with the interpreter data. Thi
s was not a real problem, but now I see fewer leaks in BoundsChecker :-).






[ Post a follow-up to this message ]



    Sponsored Links  




 





   All times are GMT. The time now is 02:58 PM.      Post New Thread    Post A Reply      
  Last Thread   Next Thread Next


Most Popular forums 

Forum Jump:
Rate This Thread:

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are ON
[IMG] code is OFF
 
Medical and Health forum | Computer Games Reviews | Graphics design forum

Back To The Top
Home | Usercp | Faq | Register