Issue 9686: asyncore infinite loop on raise (original) (raw)

Created on 2010-08-25 19:41 by mmw, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (6)
msg114931 - (view) Author: mmw (mmw) Date: 2010-08-25 19:41
def send(self, data): try: result = self.socket.send(data) return result except socket.error, why: if why.args[0] == EWOULDBLOCK: return 0 elif why.args[0] in (ECONNRESET, ENOTCONN, ESHUTDOWN, ECONNABORTED): self.handle_close() return 0 else: raise for whatever reason the connection could break client side, if you raise an anonymous exception there it's uncatchable, raise on a socket.error or dismiss async chat is a looper. that's the main reason why everybody gets this crazy infinite loop on for instance broken pipe error and the thing never exit, you just raise on your-self other and other again, BTW, you could have the same issue whatever the language, this is a developer bug.
msg114933 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-08-25 20:00
What change are you proposing?
msg114940 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2010-08-25 22:45
Could you provide a code sample which demonstrates the problem?
msg114953 - (view) Author: mmw (mmw) Date: 2010-08-26 02:33
First it depends on the socket type but might use a select call, secondable raise on a socket.error, thirdable you could call the close_handle with the message and let the guys if he would like to retry, network connection might be capricious especially for client connected through a wifi network or behind some firewall blocking port the asyncchat is a looper if you don't let him catch the exception you just create an infinite loop, this API needs a stronger model. On Wed, Aug 25, 2010 at 3:45 PM, Giampaolo Rodola' <report@bugs.python.org>wrote: > > Giampaolo Rodola' <g.rodola@gmail.com> added the comment: > > Could you provide a code sample which demonstrates the problem? > > ---------- > > _______________________________________ > Python tracker <report@bugs.python.org> > <http://bugs.python.org/issue9686> > _______________________________________ >
msg114964 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2010-08-26 11:03
I agree with you that asyncore API model is far from being robust and I've personally seen infinite recursion more than once if certain asyncore methods aren't properly subclassed. What I don't understand is what changes you are proposing and, again, it would be very helpful if you could provide an example code which demonstrates the problems you're complaining about (infinite recursion? broken pipe error? both?).
msg183759 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-03-08 19:39
I am closing this because there is no identified, fixable implementation bug in any particular Python module. The fix for the asyncore *design* will be a new, re-designed module.
History
Date User Action Args
2022-04-11 14:57:05 admin set github: 53895
2013-03-08 19:39:26 terry.reedy set stage: resolved
2013-03-08 19:39:07 terry.reedy set status: open -> closednosy: + terry.reedymessages: + resolution: not a bug
2013-03-08 19:29:12 terry.reedy set files: - unnamed
2010-08-26 11:03:50 giampaolo.rodola set messages: +
2010-08-26 02:33:08 mmw set files: + unnamedmessages: +
2010-08-25 22:45:30 giampaolo.rodola set nosy: + josiahcarlson, josiah.carlson
2010-08-25 22:45:13 giampaolo.rodola set messages: +
2010-08-25 22:36:35 rhettinger set assignee: giampaolo.rodolanosy: + giampaolo.rodola
2010-08-25 20:00:15 rhettinger set nosy: + rhettingermessages: +
2010-08-25 19:41:32 mmw create