Comment 1 for bug 496813

Specifically, the problem is that we often catch-and-retry on EINTR with operations that aren't safe to retry. Thanks very much to Martin <gzlist>, who has careful analysed the scope of the problem on the mailing list, and started writing patches towards it.

The current plan is to try use signal.siginterrupt on Python 2.6 to avoid this, at least for signal handlers that bzrlib registers. We probably should write a simple C extension for earlier Python versions to provide the same functionality.

It's possible that plugins and non-bzr programs that use bzrlib might register their own signal handlers; for them we should probably document that bzrlib doesn't expect EINTR in general so that 3rd-party code using our API ought to take care to also use siginterrupt or similar when registering signal handlers.

FWIW, the only signal handlers registered by bzrlib itself are:

 * SIGWINCH (in bzrlib/ui/text.py)
 * SIGQUIT (in bzrlib/breakin.py) [we can ignore SIGBREAK, which can't cause EINTR as it is windows-only]
 * SIGINT (in bzrlib/transport/ssh.py) — but only to install the SIG_IGN handler, and only in a child process just before exec of an SSH subprocess, so no problem there.

I'm not sure about the signal handlers that CPython installs automatically on VM startup; there's not many, but there is at least the SIGINT handler (to turn Ctrl-C into KeyboardInterrupt). So in addition to running siginterrupt for bzrlib's signal handlers for SIGWINCH and SIGQUIT, we may also want to do siginterrupt(SIGINT, False) in bzrlib.initialize(). I'll investigate further before submitting my final patch.

If using siginterrupt is a sufficient fix for this issue, as I think and hope it will be, then we can also remove until_no_eintr (after deprecating), which will make everyone happy :)