|Subject:||Re: One cause for Indy hangs found|
|Posted by:||Remy Lebeau (TeamB) (firstname.lastname@example.org)|
|Date:||Tue, 23 Aug 2005|
"Tobias Giesen" <tobi…@tgtools.de> wrote in message
> In "procedure TIdTCPConnection.GetInternalResponse"
> we will find this source code line:
> LLine := IOHandler.ReadLn;
It calls ReadLnWait(), not ReadLn().
> Which calls ReadLn with the default parameter
> AFailCount: Integer = MaxInt
> and this can and will obviously cause hangs.
So? It is supposed to. GetInternalResponse() expects a reply to be sent,
and as such is designed to wait until that reply actually arrives. Calling
ReadLnWait(MaxInt) is essentially the same as calling ReadLn() by itself,
except that the only difference between ReadLn() and ReadLnWait(MaxInt) is
that ReadLnWait() ignores empty lines. This ensures that ReadLnWait()
always returns a non-empty line to GetInternalResponse(). This is
especially important on systems that actually do sometimes send empty lines
when they are not supposed to.
One cause for Indy hangs found posted by Tobias Giesen on Tue, 23 Aug 2005