[Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

[Victor Stinner]

Le dimanche 31 août 2014, Marko Rauhamaa <marko at pacujo.net> a écrit :

> Victor Stinner <victor.stinner at gmail.com <javascript:;>>:
>
> > Sorry but I don't understand your remark. What is your problem with
> > retrying syscall on EINTR?
>
> The application will often want the EINTR return (exception) instead of
> having the function resume on its own.


This case is described as the use case #2 in the PEP, so it is supported.
As written in the PEP, if you want to be notified of the signal, set a
signal handler which raises an exception. For example the default signal
handler for SIGINT raises KeyboardInterrupt.


> > Can you please elaborate? What do you mean by "get wrong"?
>
> Proper handling of signals is difficult and at times even impossible.
> For example it is impossible to wake up reliably from the select(2)
> system call when a signal is generated (which is why linux now has
> pselect).


In my experience, using signal.set_wakeup_fd() works well with select(),
even on Windows. The PEP promotes this. It is even thread safe.

I don't know issues of signals with select() (and without a file descriptor
used to wake up it). Python now exposes signal.pthread_sigmask(), I don't
know if it helps. In my experience, signals don't play well with
multithreading. On FreeBSD, the signal is send to a "random" thread. So you
must have the same signal mask on all threads if you want to rely on them.

But I don't get you point. How does this PEP make the situation worse?

Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140831/e3939479/attachment.html>