"Stephen Odgaard" <sso@cowi.dk> wrote in message
news:4443f201@newsgroups.borland.com...
> Thanks Martin,
>
> I think I have a plan figured out by now. I have to dig one step further
> into the OnExecute infinite look.
> My current implementation of the .Execute is a ReadLn and a WriteLn.
> I can see there is a "IdTimeOutDefault = -1" defining that the "Default
> Timeout" should be used for ReadLn, but not what it is. Where can I see
> this?
> (I can see that the ReadLn(ATerminator, ATimeout, AMaxLineLength) could be
> used, to assure this is under control.)
> For WriteLn there seem not to be any timeout defined.
>
> So basically the wait (or sleep) in a Execute thread containing a ReadLn
and
> WriteLn thread is basically this mystical "Default Timeout" value...
>
AFAIK, the default *read* timeout is INFINITE, (defined in windows unit as
'DWORD($FFFFFFFF)', ie. -1).
There is no write timeout, so it is effectively INFINITE also, or at least,
it is as far as Indy goes. Write calls that get stuck because the client
has gone away are eventually timed out by the TCP timers in Winsock. These
timers have *long* intervals to accommodate all types of fast, slow,
high-latency, low-latency links. This a big problem for those designs of
'chat' app that rely on directly calling the write methods of all the
peerThreads/contexts of all clients in the global list, especially those
that keep the global list locked for the whole iteration.
Rgds,
Martin
