471,602 Members | 1,293 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,602 software developers and data experts.

Python 2.4, asyncore and errors

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.

Does anyone else agree that this should be changed? If so, what should be
the correct behavior? (I'm happy to work up a patch and submit it).


Jul 18 '05 #1
0 1659

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

699 posts views Thread by mike420 | last post: by
5 posts views Thread by Linan | last post: by
reply views Thread by Kurt B. Kaiser | last post: by
reply views Thread by GeicoGecko | last post: by
1 post views Thread by XIAOLAOHU | last post: by
reply views Thread by leo001 | last post: by
reply views Thread by CCCYYYY | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.