Updates on PEP 556
This commit is contained in:
parent
88b326e653
commit
d252fb065b
14
pep-0556.rst
14
pep-0556.rst
|
@ -117,6 +117,18 @@ should probably not mess with this setting, just as they shouldn't call
|
|||
doing so.
|
||||
|
||||
|
||||
Non-goals
|
||||
=========
|
||||
|
||||
This PEP does not address reentrancy issues with other kinds of
|
||||
asynchronous code execution (for example signal handlers registered
|
||||
with the ``signal`` module). The author believes that the overwhelming
|
||||
majority of painful reentrancy issues occur with finalizers. Most of the
|
||||
time, signal handlers are able to set a single flag and/or wake up a
|
||||
file descriptor for the main program to notice. As for those signal
|
||||
handlers which raise an exception, they *have* to execute in-thread.
|
||||
|
||||
|
||||
Internal details
|
||||
================
|
||||
|
||||
|
@ -274,7 +286,7 @@ and live inside the ``gc`` module, unless otherwise noted:
|
|||
if gc_is_threaded == True:
|
||||
# Wake up thread, asking it to end
|
||||
gc_is_threaded = False
|
||||
gc_thread..wakeup.release()
|
||||
gc_thread.wakeup.release()
|
||||
# Wait for thread exit
|
||||
Py_BEGIN_ALLOW_THREADS
|
||||
gc_thread.done.acquire()
|
||||
|
|
Loading…
Reference in New Issue