asyncore: suggested patch

[Panu A Kalliokoski]

Robert Amesz <rcameszREMOVETHIS at dds.removethistoo.nl> wrote:

> careful look at your patch *and* at asyncore.py I'm sorry to have to 
> say that your patch really totally goes against the asyncore design 
> principle of having a single poll-loop drive the system.

I took the time to watch at the original connect() of dispather at 
asyncore. The issue is basically dealt with correctly, returning to the 
select() loop when the socket is not yet connected, but if it is true, as 
Jonathan reports, that connecting to a non-existent port on an existing 
host loops forever, the problem is the unneeded use of non-blocking 
sockets and incorrect parsing of error values. What we need to know is 
what the error value is in a situation like this and how it could be known 
different from the legitimate ones (EINPROGRESS, EWOULDBLOCK ...).

> If the only thing you want to do is abort the connection attempt after 
> a certain amount of time it would be better just to simply check if the 
> connection is actually established at or after a certain point in time. 
> That should be straightforward enough, if you clone the loop() function 
> in asyncore and put the timeout-check in the 'while map:' loop.

This is also one part of functionality which is missing in asyncore: 
scheduled events (such as explicit connect() timeouts).

> (It might be better still if asyncore would be extended to handle 
> timeouts by calling two more callback-functions, say 
> handle_connect_timeout() and handle_io_timeout().)

Better still to move to my Selecting. 
(http://sange.fi/~atehwa-u/selecting-0.8/)

Panu Kalliokoski