Nathaniel Smith <[email protected]> added the comment:
> What would make it not reentrant-safe?
Probably the most obvious example of a non-reentrant-safe operation is taking a
lock. It's very natural to write code like:
def call_soon(...):
with self._call_soon_lock:
...
but now imagine that inside the body of that 'with' statement, a signal
arrives, so the interpreter pauses what it's doing to invoke the signal
handler, and the signal handler turns around and invokes call_soon, which tries
to acquire the same lock that it already holds → instant deadlock.
And this rules out quite a few of the tools you might normally expect to use in
thread-safe code, like queue.Queue, since they use locks internally.
The reason I think the stdlib's call_soon is OK is that it doesn't perform any
blocking operations, and the critical operation is simply
'self._ready.append(...)', which in CPython is atomic with respect to
threads/signals/GC.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue34968>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
