quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (MODPYTHON-114) Problems with PythonPath directive.
Date Fri, 17 Mar 2006 06:38:00 GMT
     [ http://issues.apache.org/jira/browse/MODPYTHON-114?page=all ]

Graham Dumpleton reassigned MODPYTHON-114:

    Assign To: Graham Dumpleton

> Problems with PythonPath directive.
> -----------------------------------
>          Key: MODPYTHON-114
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-114
>      Project: mod_python
>         Type: Bug
>   Components: core
>     Versions: 3.1.4, 3.2.7
>     Reporter: Graham Dumpleton
>     Assignee: Graham Dumpleton

> The "PythonPath" setting can be used to define the value of the Python "sys.path" variable.
It is this variable which defines the list of directories that Python will search in when
looking for a module to be imported.
> Although the actual reassignment of "sys.path" by mod_python does not in itself present
a problem due to assignment in Python being thread safe by definition, the context in which
the assignment occurs is not thread safe and a race condition exists.
> This exists as the top level mod_python dispatcher will consult the existing value of
"sys.path" and the last value for the "PythonPath" setting encountered before then making
a decision to modify "sys.path". If multiple requests are being serviced in distinct threads
within the context of the same interpreter instance, and each at the same time decide they
want to modify the value of "sys.path", only one might ultimately succeed in setting it to
the value it wants and any modification required by the other may be lost.
> In the worst case scenario, this can result in the importation of any subsequent modules
within that request failing due to a required directory not being present in "sys.path". It
is possible that this situation may resolve itself and go away on a subsequent request, but
due to how mod_python caches the last value of "PythonPath" in a global variable this will
be dependent on what other requests arrive.
> At the least, for mod_python to resolve the problem itself would require a request to
arrive in the interim which targeted the URL which was not the last to cache its raw setting
for "PythonPath". This only works though due to a further issue whereby alternate requests
against URLs with different "PythonPath" settings will cause "sys.path" to be extended everytime
if the "PythonPath" setting references "sys.path". This results in "sys.path" continually
growing over time due to directories being added multiple times.
> The problematic code in apache.py is:
>             if config.has_key("PythonPath"):
>                 # we want to do as little evaling as possible,
>                 # so we remember the path in un-evaled form and
>                 # compare it
>                 global _path
>                 pathstring = config["PythonPath"]
>                 if pathstring != _path:
>                     _path = pathstring
>                     newpath = eval(pathstring)
>                     if sys.path != newpath:
>                         sys.path[:] = newpath
> To fix the problems, the processing of PythonPath directive should be protected by a
thread mutex lock and a dictionary should be used to store all seen values of PythonPath rather
than a single variable. If a value for PythonPath has ever been seen, and not just from the
last change, then no update would be necessary.
>     if config.has_key("PythonPath"):
>         try:
>             _path_cache_lock.acquire()
>             pathstring = config["PythonPath"]
>             if not _path_cache.has_key(pathstring):
>                 newpath = eval(pathstring)
>                 _path_cache[pathstring] = None
>                 sys.path[:] = newpath
>         finally:
>             _path_cache_lock.release()
> There shouldn't really be a need to check whether the new path is different to the current
value of sys.path as that scenario shouldn't occur at that point.
> The two parts of this problem were previously catalogued as ISSUE 15 and ISSUE 16 in
my list of problems with the module importing system. The list can be found at:
>   http://www.dscpl.com.au/articles/modpython-003.html

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message