[issue6706] asyncore's accept() is broken

Antoine Pitrou report at bugs.python.org
Sat Sep 25 13:56:49 CEST 2010

Antoine Pitrou <pitrou at free.fr> added the comment:

> The point of frameworks such as asyncore and twisted is to hide all
> system-specific errors as much as possible and provide a portable
> interface across all platforms.

As long as these errors are reasonably explainable.
If a strange error only occurs when running nmap on an OS X server, then
it might be useful for the user to know that the OS X server isn't able
to service all connections properly due to a bug in the operating

> AFAICT, the whole point of this issue is that there should be only one
> way for an asyncore-based server to accept an incoming connection,
> possibly avoiding the user to deal with low-level details such as

I am talking specifically about the address being None (i.e., a (sock,
None) tuple is successfully returned).
EWOULDBLOCK and ECONNABORTED are documented error conditions for
accept(), but returning 0 in addrlen is not.

> As I said, in a better designed framework the user shouldn't be
> supposed to call accept() at all, but that's how asyncore is designed.

Perhaps it's time to add an alternative handle_accepted(sock, addr)
which relieves the user from calling accept() :))
Then, perhaps self.accept() shouldn't filter any errors at all, but the
default handle_accept() would silence them before calling


Python tracker <report at bugs.python.org>

More information about the Python-bugs-list mailing list