New submission from Hrvoje Nikšić <hnik...@gmail.com>:
In https://stackoverflow.com/q/53704709/1600898 a StackOverflow user asked how
the add_signal_handler event loop method differs from the signal.signal
normally used by Python code.
The add_signal_handler documentation is quite brief - if we exclude the parts
that explain the exceptions raised and how to pass keyword arguments to the
callback, the meat is this sentence:
Set callback as the handler for the signum signal.
It is only after looking at the source, and understanding asyncio, that one
comes to the conclusion that the idea is to run the handler along with other
event loop callbacks and coroutines, at the time when it is actually safe to
invoke asyncio code.
I think this deserves to be mentioned explicitly, for example:
Set callback as the handler for the signum signal.
The callback will be invoked in the thread that runs the event
loop, along with other queued callbacks and runnable coroutines.
Unlike signal handlers registered using signal.signal(), a
callback registered with this function is allowed to interact
with the event loop.
----------
assignee: docs@python
components: Documentation
messages: 331645
nosy: docs@python, hniksic
priority: normal
severity: normal
status: open
title: Document add_signal_handler
versions: Python 3.7, Python 3.8
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35465>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
