When i use non-blocking socket, connect() method of
asyncore.dispatcher class looks like works incorrect.

Example: if connection have not established then socket
merely closed and handle_error not called and no
exception throwed.

One more example: if writable() and readble() methods
returns zero than handle_connect() will never be called
even if connection will be established.

Thanks.

Logged In: YES 
user_id=410460

Patch #909005 fixes the problem.

It sounds as though the original poster is passing a socket that has been created, but which is not yet connected, to the dispatcher constructor.

We should update the documentation to state that either the user should pass a completely connected socket (as returned by socket.accept(), or which has connected as the result of a a blocking socket.connect() call), or use the .create_socket() and .connect() methods of the dispatcher.

It's about _non-blocking_ socket. Socket has been created and connect called. However, for non-blocking socket connect returns immediately. The patch allows to use connect in non-blocking manner. I don't see any reason of limiting socket to be connected in blocking manner.

According to my reading, the only change necessary to make the semantics equivalent for a non-blocking socket for which .connect() has been called is to change a portion of the dispatcher's __init__ method to:

    try:
        self.addr = sock.getpeername()
    except socket.error:
        # if we can't get the peer name, we haven't connected yet
        self.connected = False

I was working with Dmitry desk by desk :), but I don't remember, what did he really mean with his "broken" english :). The main problem was in impossibility to connect to another peer in non-blocking manner. The patch contains the workaround code, which changes original behaviour significantly. You may seek for your own way to fix blocking connect there. 

Fixed in trunk, will be fixed in 3.0 this weekend.