asyncore: suggested patch

[Panu A Kalliokoski]

Jonathan Feinberg <jdf at pobox.com> wrote:

> In the case that a host's address is bad, there was no problem;
> connect() would raise a socket.error with 'host not found'.  But in
> the case where the host is okay, but the *port* is wrong (i.e.,
> http://www.foo.com:666/), I would poll endlessly.  I found that I
> could solve the problem by overriding the connect() method in my
> subclass of async_chat, such that it takes an optional timeout
> argument, as follows:

I don't remember just now how the connecting is handled in asyncore, but 
the "correct" way to do this is to use blocking sockets and select() on 
connecting and established ones at the same time. Asyncore uses 
non-blocking sockets for reasons I haven't been able to understand, making 
it hard to do a proper all-encompassing select().

> I found that in the case where the host is legitimate, but there is
> nothing listening on the specified port, Windows 2000 raises
> EWOULDBLOCK, while NetBSD raises EINPROGRESS, which is why I check for
> both.

BTW, this is another reason not to use non-blocking sockets: the error 
codes vary from platform to platform. This is an issue that should be 
handled in the socket abstraction layer of Python, but is not.

> I like this solution, as it doesn't break any existing code, and
> solves my problem.  I don't like it, because I'm afraid that the use
> of a timeout has implications that are beyond my ken.  At any rate, I
> present it to you with the thought that you may find it useful enough
> to incorporate into asyncore.

I don't think it causes any real problems; just it would be nice to be 
able to listen to other sockets while connecting that one, wouldn't it?

Panu Kalliokoski