in spite of usage of non-blocking IO, syscalls may return EINTR if signal arrive during some syscalls.

It is desirable to re-call syscall after receiving EINTR. Trivial loops should be implemented around (recv, send, connect, accept)

Again, it's not clear to me what you are complaining about.
Please try to be more clear and/or provide a patch.

When using non-blocking IO, we issue select (or poll,epoll), and after that kernel should guarantee, that recv or send will complete immediatelly, transferring data as needed. But sometimes (as Linux is buggy), such operations results in EINTR error if some signal arrived during this call. In that case python exception generated and typically connection will be closed.
  To recover from this situation it is OK to call recv or send again in case of EINTR. All network functions (recv*, send*, accept, connect) are vulnerable for EINTR in practice.

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-02/msg00457.html

Okay, linux is not buggy :)))
EINTR may occur if SA_RESTART is not specified in sigaction.

Here's a similar bug: http://bugs.python.org/issue7978.

>EINTR may occur if SA_RESTART is not specified in sigaction.
Some syscalls (like select) will generate EINTR despite SA_RESTART. man 7 signal

It was already discussed in other issues, the issue is not specific to asyncore: Python code should not handle EINTR. IMO the C module socket should handle EINTR for you.