Author martin.panter
Recipients jwilk, martin.panter, pitrou, r.david.murray, serhiy.storchaka
Date 2015-05-25.07:28:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1432538925.77.0.116646998626.issue22350@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2015-05-25 07:28:45martin.pantersetrecipients: + martin.panter, pitrou, jwilk, r.david.murray, serhiy.storchaka
2015-05-25 07:28:45martin.pantersetmessageid: <1432538925.77.0.116646998626.issue22350@psf.upfronthosting.co.za>
2015-05-25 07:28:45martin.panterlinkissue22350 messages
2015-05-25 07:28:45martin.pantercreate