Update TIdIOHandler.ConnectTimeout logic

[rlebeau]

Update TIdIOHandler to pass its ConnectTimeout value all the way to TIdStack.Connect() to get the timeout logic out of TIdIOHandler.ConnectClient(). This way, TIdStackWindows can be updated to use WSA...() functions when available (ie, WSAConnectByName() or WSAConnectByList(), which both have a timeout parameter), and thus avoid having to use the TIdConnectThread class to abort the connection after the timeout elapsed. Other TIdStack... classes can continue using TIdConnectThread when suitable platform-specific techniques are not available.

[rlebeau]

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.

[rlebeau]

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

[gec75]

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?

[rlebeau]

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.

[rlebeau]

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.