Message244016
For the record, the SMTP scenario was Issue 17498, where code that is about to raise an exception attempts an RSET command that could also fail.
I do think each change in my patch is essentially the same case: restoring the invariant expected by the __exit__() method, that either the protocol state allows QUIT, or there is no connection. But I agree it may help divide this into smaller pieces. I am uploading getlongresp-loop.patch, which fixes just the receiving loop in _getlongresp().
I have also added some logic to avoid errors raised when flushing and closing the socket do not mask the original exception, which I understand David was concerned about. I guess it is possible (though unlikely) that an EPIPE or ECONNRESET flushing the send buffer could mask a KeyboardInterrupt raised inside the loop.
Sorry I took a while to follow up on this, but please have a look and let me know if this simplified patch makes any sense. |
|
Date |
User |
Action |
Args |
2015-05-25 07:28:45 | martin.panter | set | recipients:
+ martin.panter, pitrou, jwilk, r.david.murray, serhiy.storchaka |
2015-05-25 07:28:45 | martin.panter | set | messageid: <1432538925.77.0.116646998626.issue22350@psf.upfronthosting.co.za> |
2015-05-25 07:28:45 | martin.panter | link | issue22350 messages |
2015-05-25 07:28:45 | martin.panter | create | |
|