This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author giampaolo.rodola
Recipients BreamoreBoy, dmalcolm, giampaolo.rodola, josiahcarlson, matejcik, pitrou, santoso.wijaya
Date 2010-09-25.12:34:53
SpamBayes Score 3.6823158e-06
Marked as misclassified No
Message-id <>
> 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 system.

It might be useful to find whether this is tracked somewhere.
For the record, here (comment #10) is a code which should reproduce this problem:
As for what asyncore should in this case I think it should theoretically be safe for accept() to return (sock, None). What usually happen after that is that the socket object is passed to another dispatcher subclass (the handler) and the connection gets automatically closed once recv() or send() get called on the next async-loop.

> Perhaps it's time to add an alternative handle_accepted(sock, addr)
> which relieves the user from calling accept() :))

This sounds like a very good idea for 3.2.
As for 3.1 and 2.7 (2.6?) I think it can be useful to suppress EWOULDBLOCK/ECONNABORTED and return None instead.
Considering accept() can *already* return None it wouldn't break backward compatibility.
Date User Action Args
2010-09-25 12:34:55giampaolo.rodolasetrecipients: + giampaolo.rodola, josiahcarlson, pitrou, matejcik, dmalcolm, santoso.wijaya, BreamoreBoy
2010-09-25 12:34:55giampaolo.rodolasetmessageid: <>
2010-09-25 12:34:54giampaolo.rodolalinkissue6706 messages
2010-09-25 12:34:53giampaolo.rodolacreate