Automatically retry EINTR for Python < 3.5 to prevent duplicate command execution

[thomasst]

The problem

Redis-py's execute commands (StrictRedis.execute_command and BasePipeline.execute) perform poor exception handling, and simply retry the entire command or pipeline in case there is a ConnectionError). Similarly, SocketBuffer._read_from_socket (and similar) perform poor exception handling, and don't check for errors like EINTR that may happen at any time during a system call if the process has signal handlers set up. The proper handling of EINTR is to retry the system call, which Python 3.5 already does (https://www.python.org/dev/peps/pep-0475/), but we need to do this in client code for older versions of Python.

How to reproduce

Run the following script:

import redis import os import signal print 'PID', os.getpid() conn = redis.Redis() def h(*args, **kwargs): print 'signal handler', args, kwargs signal.signal(signal.SIGINT, h) signal.signal(signal.SIGTERM, h) conn.delete('x') for x in range(1000000): conn.lpush('x', x) 

In a separate shell, execute kill PID several times, where PID is the PID of the script above. Then, execute kill -9 PID to kill the script. When you verify the length of 'x', you will see that it most likely won't match up with the number that was pushed since the list now contains duplicate items.

[carltongibson]

@thomasst This looks great. What's you thought on adding some kind of test harness around it? (I like PRs with tests.)

The change proposed here is very clean. Having read the PEP and looked at #565 I think, yeah, why not? — If redis-py can handle this so neatly then it seems like a good addition.

[thomasst]

Not sure what a good way would be to test it. We would have to delay the read, fork a process that triggers a signal while the read is pending, and ensure the read gets retried?

[carltongibson]

Yeah. That sounds about right. I don't know if it's worth the effort.

[andymccurdy]

Thanks, this looks great.

[thomasst]

Thanks! @andymccurdy mind pushing a new release out soon? The last one on pypi is a bit dated from 2015-11-03.