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.
|
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
|
Internal details
|
||||||
================
|
================
|
||||||
|
|
||||||
|
@ -274,7 +286,7 @@ and live inside the ``gc`` module, unless otherwise noted:
|
||||||
if gc_is_threaded == True:
|
if gc_is_threaded == True:
|
||||||
# Wake up thread, asking it to end
|
# Wake up thread, asking it to end
|
||||||
gc_is_threaded = False
|
gc_is_threaded = False
|
||||||
gc_thread..wakeup.release()
|
gc_thread.wakeup.release()
|
||||||
# Wait for thread exit
|
# Wait for thread exit
|
||||||
Py_BEGIN_ALLOW_THREADS
|
Py_BEGIN_ALLOW_THREADS
|
||||||
gc_thread.done.acquire()
|
gc_thread.done.acquire()
|
||||||
|
|
Loading…
Reference in New Issue