Just curious, I started the thread because I was seeing issues with my
server not behaving properly. I have also discovered that when debugging the
client end of the app, Ctrl-F2 to reset the app while debugging will cause
the issue 8 out of 10 times.
I would like to raise my question again based on the following statement:
>>>>If a dead client socket then the SendFrom may take a lot of time
till
>>>> disconnect detected. This is going to block the other threads
trying to
>>>> access the server.threads list and also this is going to create a
delay
This sounds like the issue I am having. If this is related, how can it be
handled gracefully.
Not being familiar enough with the Indy component, I'd like to pose what may
be a stupid question. Is it possible to poll the clients periodically to see
if they are alive, if not, then kill the thread gracefully.
"Jamie Dale" <j.dale@turboz.net> wrote in message
news:44897b6c@newsgroups.borland.com...
>> that one below is a potentially problemous :
>>
>>> procedure TMyPeerThread.SendToUser(const AUser, AMsg: String);
>>> var
>>> List: TList;
>>> I: Integer;
>>> begin
>>> List := Connection.Server.Threads.LockList;
>>> try
>>> For I := 0 to List.Count-1 do
>>> begin
>>> with TMyPeerThread(List[I]) do
>>> begin
>>> if AnsiSameText(Username, AUser) then
>>> begin
>>> SendFrom(Self.Username, AMsg);
>>> Exit;
>>> end;
>>> end;
>>> end;
>>> finally
>>> Connection.Server.Threads.UnlockList;
>>> end;
>>> end;
>>
>> I had many many problems using a similar approach above. Especially when
>> the
>> communication is time critical or long delays are not allowed.
>> If a dead client socket then the SendFrom may take a lot of time till
>> disconnect detected. This is going to block the other threads trying to
>> access the server.threads list and also this is going to create a delay
>> for
>> the threads that are after the "dead" one in receiving the message.
>> It is better to create a queue and either use a "writer thread" for each
>> client thread to pull and read or check the queue for new data
>> periodically
>> from the TMyPeerThread .
>> Well either ways are possible - all depends what you feel will do a
>> better
>> job for you.
>> Regards
>
> Blimey!
>
> Well, seems I'm now apparently stuffed either way!
>
> Remy? - Any thoughts? (PS, thanks for the code sample!)
