[Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR (original) (raw)
Marko Rauhamaa marko at pacujo.net
Mon Sep 1 00:15:12 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 ]
Ethan Furman <ethan at stoneleaf.us>:
On 08/31/2014 02:19 PM, Marko Rauhamaa wrote:
The application will often want the EINTR return (exception) instead of having the function resume on its own. Examples? As an ignorant person in this area, I do not know why I would ever want to have EINTR raised instead just getting the results of, say, my read() call.
Say you are writing data into a file and it takes a long time (because there is a lot of data or the medium is very slow or there is a hardware problem). You might have designed in a signaling scheme to address just this possibility. Then, the system call had better come out right away without trying to complete the full extent of the call.
If a signal is received when read() or write() has completed its task partially (> 0 bytes), no EINTR is returned but the partial count. Obviously, Python should take that possibility into account so that raising an exception in the signal handler (as mandated by the PEP) doesn't cause the partial result to be lost on os.read() or os.write().
Marko
- 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 ]