[New-bugs-announce] [issue8003] Fragile and unexpected error-handling in asyncore

Mads Kiilerich report at bugs.python.org
Tue Feb 23 19:07:44 CET 2010


New submission from Mads Kiilerich <mads at kiilerich.com>:

I had an issue which seems to be very similar to issue4690 - but different.

I created a subclass of asyncore.dispatcher, .create_socket added it to the channel map, but then .bind failed (because the port was in use - my bad), .listen wasn't called, and .accepting thus not set. The problem is that .accepting is the safeguard against .handle_read and .handle_write ever being called. Without that safeguard it then started spinning in .handle_read and .handle_write, calling handlers that wasn't implemented. 

I guess the right way to handle this is to handle exceptions thrown by .bind and then call .close. But even if I do that there will be a race-condition between the error occurs and I can call .close.

My main issue/request is that asyncore should be less fragile and handle such errors better. I don't know exactly how that should be implemented, but I think it is a reasonable expectation that no handlers (except for an error handler) is called on a dispatcher until a .connect or .listen has completed. It seems odd to have to implement .handle_write just to call .send just to trigger .handle_close which then must be implemented to call .close. Perhaps a flag could keep track of the "under construction" state (instead of assuming that it is either accepting, ready to connect, or connected).

I also notice that if .handle_read_event ever gets called on a closed (listen) socket then it will end up in .handle_connect_event which is very wrong.

Using python-2.6.2-4.fc12.i686, but it seems to be the same on release2.6-maint.

----------
components: Library (Lib)
messages: 99942
nosy: kiilerix
severity: normal
status: open
title: Fragile and unexpected error-handling in asyncore
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8003>
_______________________________________


More information about the New-bugs-announce mailing list