Indy 10 version of IdPeerThread.stop

[rlebeau]

So based on your post - that would be replaced with "TIdYarnOfThread(TIdContext(List.Items[index]).Yarn).Thread.Stop();". - for direct update.

Yes.

However, that being said, this is pretty dangerous code in general.

You are not doing any bounds checking on indexing into the Contexts list. There is a race condition where clients could connect/disconnect before you can lock the list, thus altering the index of the client you are intending to send to.

Also, you are keeping the list locked while sending. If the receiving client is dead/frozen, and its receiving buffer fills up, the send could freeze up, and then you would have a deadlock scenario that prevents other clients from connecting/disconnecting properly.

In general, I do not recommend sending unsolicited data directly to clients outside of the OnExecute event, if you can help it. I typically recommend storing unsolicited data in a per-client thread-safe queue and letting the OnExecute event send the queue when it is safe to do so, in between other reads/sends. This way, you don't have any conflicts with other data being sent by OnExecute for command responses.

But, if OnExecute doesn't send other data, then doing a direct send in this manner could work safely, if you are careful. And your protocol would have to be designed to support unsolicited data to begin with.

I certainly do not recommend terminating threads manually, though. In this case, I would probably just call Disconnect()/Binding.CloseSocket() on the failed client, and let the server cleanup the thread on its own time.