<br><br><div class="gmail_quote">On Mon, Feb 15, 2010 at 9:27 PM, Martin Pool <span dir="ltr"><<a href="mailto:mbp@canonical.com">mbp@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 16 February 2010 13:01, Martin (gzlist) <<a href="mailto:gzlist@googlemail.com">gzlist@googlemail.com</a>> wrote:<br>
> On 16/02/2010, Martin Pool <<a href="mailto:mbp@canonical.com">mbp@canonical.com</a>> wrote:<br>
>><br>
>> We still support python back to 2.4; considering the deployed<br>
>> environment of interpreters we prefer to work around bugs in Python if<br>
>> at all feasible.<br>
><br>
> The existing code does not work on either Python 2.4 or Python 2.5 so<br>
> a backout can't do any harm there. Whether it's worth addressing this<br>
> (mostly harmless) corner case on old versions is your call, getting<br>
> the solid fix in a 2.6 dot release is by far the cleanest option.<br>
<br>
</div>...<br>
<div class="im"><br>
>> Yes, but isn't it harmless to check for them?<br>
>><br>
>> Similarly, I raised the issue in review that some python calls already<br>
>> handle eintr or partial reads, but it seems harmless to check for it.<br>
><br>
> There is some harm, first it still causes the bugs as with module<br>
> cleanup, second it misleads people reading the code. Keeping a few<br>
> catches that won't do anything on some platforms is reasonable though.<br>
><br>
>> So perhaps we should have a decorator object that does handle eintr<br>
>> and install that only when needed?<br>
><br>
> The problem is the check is needed in several cases where there is<br>
> nothing you can do in client code but die, as it's not possible to<br>
> resume. There are options when it comes to a complete fix, I can<br>
> prepare a couple of branches for review and y'all can pick one.<br>
<br>
</div>OK, I see. From your first mail I thought you meant that there were<br>
just checks around some lower-level routines that would never raise<br>
it. But you're saying that some Python library routines may propagate<br>
eintr, but they can't be safely restarted? That certainly sucks.<br>
Perhaps we can avoid these routines altogether, using socket.recv<br>
directly rather than socket objects?<br></blockquote><div><br></div><div>Yeah there certainly were Python bugs that could result in an EINTR exception being raised from a non-restartable api. See [3] for the changes to fix that.</div>
<div><br></div><div>sendall() is easy to implement in python. fixing the read and readline methods is more work but you could probably monkeypatch good implementations in or even conditionally backport and monkeypatch part or all of socket.py from trunk.</div>
<div><br></div></div>