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

Victor Stinner <victor.stinner@gmail.com>:

> 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