[Python-Dev] PEP 475 accepted

[Giampaolo Rodola']

On Mon, Feb 2, 2015 at 10:46 PM, Victor Stinner <victor.stinner at gmail.com>
wrote:

> 2015-02-02 22:11 GMT+01:00 Giampaolo Rodola' <g.rodola at 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 at 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
>

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?

-- 
Giampaolo - http://grodola.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150203/c422dd73/attachment.html>