(original) (raw)

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