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.
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> > _______________________________________ >
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?).
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