[Python-Dev] EINTR handling... (original) (raw)
Charles-François Natali cf.natali at gmail.com
Fri Aug 30 12:29:12 CEST 2013
- Previous message: [Python-Dev] Add function to signal module for getting main thread id
- Next message: [Python-Dev] EINTR handling...
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hello,
This has been bothering me for years: why don't we properly handle EINTR, by running registered signal handlers and restarting the interrupted syscall (or eventually returning early e.g. for sleep)?
EINTR is really a nuisance, and exposing it to Python code is just pointless.
Now some people might argue that some code relies on EINTR to interrupt a syscall on purpose, but I don't really buy it: it's highly non-portable (depends on the syscall, SA_RESTART flag...) and subject to race conditions (it it comes before the syscall or if you get a partial read/write you'll deadlock).
Furthermore, the stdlib code base is not consistent: some code paths handle EINTR, e.g. subprocess, multiprocessing, sock_sendall() does but not sock_send()... Just grep for EINTR and InterruptedError and you'll be amazed.
GHC, the JVM and probably other platforms handle EINTR, maybe it's time for us too?
Just for reference, here are some issues due to EINTR popping up: http://bugs.python.org/issue17097 http://bugs.python.org/issue12268 http://bugs.python.org/issue9867 http://bugs.python.org/issue7978 http://bugs.python.org/issue12493 http://bugs.python.org/issue3771
cf
- Previous message: [Python-Dev] Add function to signal module for getting main thread id
- Next message: [Python-Dev] EINTR handling...
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]