You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Graham Dumpleton (JIRA)" <ji...@apache.org> on 2006/03/21 22:14:58 UTC
[jira] Created: (MODPYTHON-150) make_obcallback not thread
protected
make_obcallback not thread protected
------------------------------------
Key: MODPYTHON-150
URL: http://issues.apache.org/jira/browse/MODPYTHON-150
Project: mod_python
Type: Bug
Components: core
Versions: 3.2.8, 3.1.4
Reporter: Graham Dumpleton
Assigned to: Graham Dumpleton
In get_interpreter() function of src/mod_python.c the check of whether or not the callback object has been created is not within the bounds of the acquisition of the interpreters lock. As a result, in a multithreaded MPM, although the creation of the interpreter itself is protected so that only one thread will get to create it, multiple threads may decide the need to call make_obcallback().
In the past this hasn't mattered, but now that apache.init() is doing more complicated things, such as caching parameters as global variables and also doing fiddles with the callback object to allow optional use of new module importer, problems can start to arise.
To fix the issue the release of the interpreters lock needs to be moved to the end of the get_interpreter() function.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (MODPYTHON-150) make_obcallback not thread
protected
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-150?page=all ]
Graham Dumpleton resolved MODPYTHON-150:
----------------------------------------
Fix Version: 3.3
Resolution: Fixed
> make_obcallback not thread protected
> ------------------------------------
>
> Key: MODPYTHON-150
> URL: http://issues.apache.org/jira/browse/MODPYTHON-150
> Project: mod_python
> Type: Bug
> Components: core
> Versions: 3.2.8, 3.1.4
> Reporter: Graham Dumpleton
> Assignee: Graham Dumpleton
> Fix For: 3.3
>
> In get_interpreter() function of src/mod_python.c the check of whether or not the callback object has been created is not within the bounds of the acquisition of the interpreters lock. As a result, in a multithreaded MPM, although the creation of the interpreter itself is protected so that only one thread will get to create it, multiple threads may decide the need to call make_obcallback().
> In the past this hasn't mattered, but now that apache.init() is doing more complicated things, such as caching parameters as global variables and also doing fiddles with the callback object to allow optional use of new module importer, problems can start to arise.
> To fix the issue the release of the interpreters lock needs to be moved to the end of the get_interpreter() function.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MODPYTHON-150) make_obcallback not thread protected
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MODPYTHON-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Graham Dumpleton closed MODPYTHON-150.
--------------------------------------
> make_obcallback not thread protected
> ------------------------------------
>
> Key: MODPYTHON-150
> URL: https://issues.apache.org/jira/browse/MODPYTHON-150
> Project: mod_python
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1.4, 3.2.8
> Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> In get_interpreter() function of src/mod_python.c the check of whether or not the callback object has been created is not within the bounds of the acquisition of the interpreters lock. As a result, in a multithreaded MPM, although the creation of the interpreter itself is protected so that only one thread will get to create it, multiple threads may decide the need to call make_obcallback().
> In the past this hasn't mattered, but now that apache.init() is doing more complicated things, such as caching parameters as global variables and also doing fiddles with the callback object to allow optional use of new module importer, problems can start to arise.
> To fix the issue the release of the interpreters lock needs to be moved to the end of the get_interpreter() function.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (MODPYTHON-150) make_obcallback not thread
protected
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-150?page=all ]
Work on MODPYTHON-150 started by Graham Dumpleton
> make_obcallback not thread protected
> ------------------------------------
>
> Key: MODPYTHON-150
> URL: http://issues.apache.org/jira/browse/MODPYTHON-150
> Project: mod_python
> Type: Bug
> Components: core
> Versions: 3.2.8, 3.1.4
> Reporter: Graham Dumpleton
> Assignee: Graham Dumpleton
>
> In get_interpreter() function of src/mod_python.c the check of whether or not the callback object has been created is not within the bounds of the acquisition of the interpreters lock. As a result, in a multithreaded MPM, although the creation of the interpreter itself is protected so that only one thread will get to create it, multiple threads may decide the need to call make_obcallback().
> In the past this hasn't mattered, but now that apache.init() is doing more complicated things, such as caching parameters as global variables and also doing fiddles with the callback object to allow optional use of new module importer, problems can start to arise.
> To fix the issue the release of the interpreters lock needs to be moved to the end of the get_interpreter() function.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira