Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
erp5
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
amrani
erp5
Commits
c13c591d
Commit
c13c591d
authored
Jun 17, 2015
by
Arnaud Fontaine
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
ZODB Components: Fix deadlock between import lock and aq_method_lock.
parent
5ad424bf
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
84 additions
and
88 deletions
+84
-88
product/ERP5Type/dynamic/component_package.py
product/ERP5Type/dynamic/component_package.py
+84
-88
No files found.
product/ERP5Type/dynamic/component_package.py
View file @
c13c591d
...
@@ -241,25 +241,6 @@ class ComponentDynamicPackage(ModuleType):
...
@@ -241,25 +241,6 @@ class ComponentDynamicPackage(ModuleType):
As per PEP-302, raise an ImportError if the Loader could not load the
As per PEP-302, raise an ImportError if the Loader could not load the
module for any reason...
module for any reason...
"""
"""
# In Python < 3.3, the import lock is a global lock for all modules:
# http://bugs.python.org/issue9260
#
# So, release the import lock acquired by import statement on all hooks to
# load objects from ZODB. When an object is requested from ZEO, it sends a
# RPC request and lets the asyncore thread gets the reply. This reply may
# be a tuple (PICKLE, TID), sent directly to the first thread, or an
# Exception, which tries to import a ZODB module and thus creates a
# deadlock because of the global import lock
#
# Also, handle the case where find_module() may be called without import
# statement as it does change anything in sys.modules
import_lock_held
=
True
try
:
imp
.
release_lock
()
except
RuntimeError
:
import_lock_held
=
False
try
:
site
=
getSite
()
site
=
getSite
()
name
=
fullname
[
len
(
self
.
_namespace_prefix
):]
name
=
fullname
[
len
(
self
.
_namespace_prefix
):]
...
@@ -327,15 +308,8 @@ class ComponentDynamicPackage(ModuleType):
...
@@ -327,15 +308,8 @@ class ComponentDynamicPackage(ModuleType):
source_code_str
=
component
.
getTextContent
(
validated_only
=
True
)
source_code_str
=
component
.
getTextContent
(
validated_only
=
True
)
version_package
=
self
.
_getVersionPackage
(
version
)
version_package
=
self
.
_getVersionPackage
(
version
)
finally
:
# Internal release of import lock at the end of import machinery will
# fail if the hook is not acquired
if
import_lock_held
:
imp
.
acquire_lock
()
# All the required objects have been loaded, acquire import lock to modify
# All the required objects have been loaded, acquire import lock to modify
# sys.modules and execute PEP302 requisites
# sys.modules and execute PEP302 requisites
if
not
import_lock_held
:
imp
.
acquire_lock
()
imp
.
acquire_lock
()
try
:
try
:
# The module *must* be in sys.modules before executing the code in case
# The module *must* be in sys.modules before executing the code in case
...
@@ -393,10 +367,6 @@ class ComponentDynamicPackage(ModuleType):
...
@@ -393,10 +367,6 @@ class ComponentDynamicPackage(ModuleType):
return
module
return
module
finally
:
finally
:
# load_module() can be called outside of import machinery, for example
# to check first if the module can be handled by Component and then try
# to load it without going through the same code again
if
not
import_lock_held
:
imp
.
release_lock
()
imp
.
release_lock
()
def
load_module
(
self
,
fullname
):
def
load_module
(
self
,
fullname
):
...
@@ -404,8 +374,34 @@ class ComponentDynamicPackage(ModuleType):
...
@@ -404,8 +374,34 @@ class ComponentDynamicPackage(ModuleType):
Make sure that loading module is thread-safe using aq_method_lock to make
Make sure that loading module is thread-safe using aq_method_lock to make
sure that modules do not disappear because of an ongoing reset
sure that modules do not disappear because of an ongoing reset
"""
"""
with
aq_method_lock
:
# In Python < 3.3, the import lock is a global lock for all modules:
# http://bugs.python.org/issue9260
#
# So, release the import lock acquired by import statement on all hooks to
# load objects from ZODB. When an object is requested from ZEO, it sends a
# RPC request and lets the asyncore thread gets the reply. This reply may
# be a tuple (PICKLE, TID), sent directly to the first thread, or an
# Exception, which tries to import a ZODB module and thus creates a
# deadlock because of the global import lock
#
# Also, handle the case where find_module() may be called without import
# statement as it does change anything in sys.modules
import_lock_held
=
True
try
:
imp
.
release_lock
()
except
RuntimeError
:
import_lock_held
=
False
aq_method_lock
.
acquire
()
try
:
return
self
.
__load_module
(
fullname
)
return
self
.
__load_module
(
fullname
)
finally
:
aq_method_lock
.
release
()
# Internal release of import lock at the end of import machinery will
# fail if the hook is not acquired
if
import_lock_held
:
imp
.
acquire_lock
()
def
find_load_module
(
self
,
name
):
def
find_load_module
(
self
,
name
):
"""
"""
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment