Incorrect handling of EINTR in Bazaar

[Martin Pool]

On 16 February 2010 13:01, Martin (gzlist) <gzlist at googlemail.com> wrote:
> On 16/02/2010, Martin Pool <mbp at canonical.com> wrote:
>>
>> We still support python back to 2.4; considering the deployed
>> environment of interpreters we prefer to work around bugs in Python if
>> at all feasible.
>
> The existing code does not work on either Python 2.4 or Python 2.5 so
> a backout can't do any harm there. Whether it's worth addressing this
> (mostly harmless) corner case on old versions is your call, getting
> the solid fix in a 2.6 dot release is by far the cleanest option.

...

>> Yes, but isn't it harmless to check for them?
>>
>> Similarly, I raised the issue in review that some python calls already
>> handle eintr or partial reads, but it seems harmless to check for it.
>
> There is some harm, first it still causes the bugs as with module
> cleanup, second it misleads people reading the code. Keeping a few
> catches that won't do anything on some platforms is reasonable though.
>
>> So perhaps we should have a decorator object that does handle eintr
>> and install that only when needed?
>
> The problem is the check is needed in several cases where there is
> nothing you can do in client code but die, as it's not possible to
> resume. There are options when it comes to a complete fix, I can
> prepare a couple of branches for review and y'all can pick one.

OK, I see.  From your first mail I thought you meant that there were
just checks around some lower-level routines that would never raise
it.  But you're saying that some Python library routines may propagate
eintr, but they can't be safely restarted?  That certainly sucks.
Perhaps we can avoid these routines altogether, using socket.recv
directly rather than socket objects?

-- 
Martin <http://launchpad.net/~mbp/>