Changes in asyncore from 2.3 to 2.4 mean that
asyncore.poll() now passes all the sockets in the map
to select.select() to be checked for errors, which is
probably a good thing.  If an error occurs, then
handle_expt() is called, which by default logs the error.

asyncore.dispatcher creates nonblocking sockets.  When
connect_ex() is called on a nonblocking socket, it will
probably return EWOULDBLOCK (connecting takes time),
which may mean the connection is successful, or may not
(asyncore dispatcher keeps going assuming all is well).

If the connection is not successful, and then
asyncore.loop() is called, then select.select() will
indicate that there is an error with the socket (can't
connect) and the error will be logged.

The trouble is that asyncore.loop then keeps going, and
will log this error again.  My not-that-fast system
here gets about 10,000 logged messages per second with
a single socket in the asyncore map.

There are ways to avoid this:

  (1) if the socket is blocking when connect()ing (and
then nonblocking afterwards) an error is raised if the
connect fails.

  (2) Before calling asyncore.loop(), the caller can
run through all the sockets, checking that they are ok.

  (3) handle_expt() can be overridden with a function
that repairs or removes the socket from the map (etc)

However, I'm not convinced that this is good behavior
for asyncore to have, by default.  On Windows,
select.select() will only indicate an error when trying
to connect (nonblocking) or if SO_OOBINLINE is
disabled, but this may not be the case (i.e. errors can
occur at other times) with other platforms, right? 
Unless the error is temporary, asyncore will by default
start streaming (extremely fast) a lot of "warning:
unhandled exception" (not very helpful an error
message, either) messages.  Even if the error only
lasts a minute, that could easily result in 10,000
warnings being logged.

Do any of the python developers agree that this is a
flaw?  I'm happy to work up a patch for whatever the
desired solution is, if so.