[Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Mon Sep 1 14:58:18 CEST 2014
- Previous message: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR
- Next message: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi,
I'm +1 on the whole PEP.
Writing a signal handler is difficult, only "async-signal safe" functions can be called.
You mean a C signal handler? Python signal handlers are not restricted.
Some signals are not interesting and should not interrupt the the application. There are two options to only interrupt an application on some signals:
* Raise an exception in the signal handler, like
KeyboardInterrupt
forSIGINT
* Use a I/O multiplexing function likeselect()
with the Python signal "wakeup" file descriptor: see the functionsignal.setwakeupfd()
.
This section looks a bit incomplete. Some calls such as os.read() or os.write() will (should) return a partial result when interrupted and they already handled >0 bytes. Perhaps other functions have a similar behaviour?
On Unix, the
asyncio
module uses the wakeup file descriptor to wake up its event loop.
How about Windows?
Regards
Antoine.
- Previous message: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR
- Next message: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]