Update TIdIOHandler.ConnectTimeout logic about indy HOT 5 OPEN

Alternatively, update TIdIOHandlerStack.ConnectClient() to put the socket into non-blocking mode, if possible, before calling connect(), then use select() to handle the timeout, and then restore the socket to blocking mode if the connection is successful.

from indy.

From duplicate #466

I have an application where I need a very short connect timeout.
Then I just saw that Indy starts a new thread for this connect ...!?
I took the time to implement a version based on non blocking connect and select... see attached patch.
The idea is to split TIdSocketHandle.Connect into GStack.Connect (which starts an non-blocking connect) and later UpdateBinding.
The code in TIdIOHandlerStack.ConnectClient just starts connect then waits with select (write) and then decides to UpdateBinding or raise exception.
I also added the TIdSocketListWindows.SelectWrite... why was it not yet included??
It's just a prof of concept code, no AntiFreeze and no posix variant.

indy_asyc_connect.patch

from indy.

I don't really care about small implementation details :), the idea is that matters.
But is there a reason why Select(write) aka. "Writable" is NOT exposed somehow?

from indy.

is there a reason why Select(write) aka. "Writable" is NOT exposed somehow?

There is currently nothing in Indy that waits for a socket to be in a writable state before writing data to it, Indy just writes and lets it block as needed. Indy is designed around blocking I/O, not non-blocking I/O. So, there just hasn't been any need for a high-level wrapper to call select() for writing, only for reading (since there are a few places where Indy does wait for readable states).

That being said, Indy does expose one way to call select() for writing - the TIdSocketList class has a public virtual Select() class method which has an AWriteList parameter which is fully implemented, just never used by Indy itself. But I don't see why you could not call it directly if you needed to.

from indy.

Apparently, a recent change in Linux now prevents one thread from disconnecting a TCP socket if other threads are waiting on the socket!

This does not bode well for Indy, which expects to be able to shutdown/close a TCP socket while threads are blocked on socket I/O operations. For this ticket, this change means that using connect() in non-blocking mode now becomes more important, otherwise ConnectTimeout becomes useless as a blocked connect() will no longer unblock when shutdown() is called.

Will have to review other socket functions for potential problems introduced by this change.

from indy.