T
Tony Meyer
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).
=Tony.Meyer
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).
=Tony.Meyer