asyncore: suggested patch
Panu A Kalliokoski
pkalliok at cc.helsinki.fi
Thu May 31 11:53:22 CEST 2001
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.
More information about the Python-list