On 02/02/2015 12:58 PM, Victor Stinner wrote:

2015-02-02 21:49 GMT+01:00 Guido van Rossum <guido@python.org>:

...

W00t! Congratulations les Français! We will celebrate this acceptance with a glass of red wine and cheese.

If it were me, I'd use separate glasses. //arry/

On Mon, 2 Feb 2015 12:49:32 -0800 Guido van Rossum <guido@python.org> wrote:

W00t! Congratulations les Français!

I hoped nobody would notice :-) Regards Antoine.

On Mon, Feb 2, 2015 at 12:45 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:

...

Hello,

I'm now accepting PEP 475 - "Retry system calls failing with EINTR". You can read it at https://www.python.org/dev/peps/pep-0475/

The implementation is more or less ready at http://bugs.python.org/issue23285, so you can expect it to land in the main repo relatively soon.

Regards

Antoine.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org

2015-02-02 22:11 GMT+01:00 Giampaolo Rodola' <g.rodola@gmail.com>:

I may be chiming in a little late, however, I'd have a question: does this affect non-blocking applications somehow? How often should we expect to receive EINTR?

Each time a program is interrupted by a signal while it was waiting for a sycall. Most syscalls are fast, especially in an application written with non blocking operations. For example, timeit says that os.getuid() takes 370 nanoseconds (on Linux). getpid() only takes 285 nanoseconds, but it looks to be cached in the libc: strace doesn't show me syscalls. Network syscalls are probably slower. haypo@selma$ ./python -Wignore -m timeit -s 'import socket; s,c=socket.socketpair()' 's.send(b"a"); c.recv(1)' 100000 loops, best of 3: 2.26 usec per loop

Is it correct to state that in case many EINTR signals are sent repeatedly a non-blocking framework such as asyncio may hang for "too long"?

A syscall fails with EINTR each time it gets a signal. You are unlikely if the same syscall requires to be retried twice (executed 3 times) because it got EINTR twice. I don't see why the kernel would make a syscall fails EINTR multiple times. asyncio doesn't process the signal immediatly. asyncio uses signal.set_wakeup_fd(). At the C level, the C signal handler writes the signal number into a pipe. At the Python level, the selector is awaken by the write. Later, asyncio executes the Python handler of the signal (if a Python signal handler was registered). A nice side effect of the PEP is to avoid to awake the application if it's not necessary. If no Python signal handler is registered, no byte is written into the pipe, the selector continues to wait for events. Victor

2015-02-03 15:25 GMT+01:00 Giampaolo Rodola' <g.rodola@gmail.com>:

OK, thanks for clarifying, this is a very nice addition. One last thing: should InterruptedError exception be deprecated? As far as I understand it should never occur again, right?

signal.setinterrupt() is not deprecated so you can still "disable" the PEP for a specific signal. Charles-François didn't want to deprecate this function. https://docs.python.org/dev/library/signal.html#signal.siginterrupt Since the code to handle InterruptedError will be removed from the stdlib, the purpose of this function becomes less obvious to me... Victor