classification
Title: asyncore infinite loop on raise
Type: Stage: resolved
Components: Library (Lib) Versions: Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: giampaolo.rodola Nosy List: giampaolo.rodola, josiah.carlson, josiahcarlson, mmw, rhettinger, terry.reedy
Priority: normal Keywords:

Created on 2010-08-25 19:41 by mmw, last changed 2013-03-08 19:39 by terry.reedy. 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
2013-03-08 19:39:26terry.reedysetstage: resolved
2013-03-08 19:39:07terry.reedysetstatus: open -> closed

nosy: + terry.reedy
messages: + msg183759

resolution: not a bug
2013-03-08 19:29:12terry.reedysetfiles: - unnamed
2010-08-26 11:03:50giampaolo.rodolasetmessages: + msg114964
2010-08-26 02:33:08mmwsetfiles: + unnamed

messages: + msg114953
2010-08-25 22:45:30giampaolo.rodolasetnosy: + josiahcarlson, josiah.carlson
2010-08-25 22:45:13giampaolo.rodolasetmessages: + msg114940
2010-08-25 22:36:35rhettingersetassignee: giampaolo.rodola

nosy: + giampaolo.rodola
2010-08-25 20:00:15rhettingersetnosy: + rhettinger
messages: + msg114933
2010-08-25 19:41:32mmwcreate