"turan kolin" <none@none.com> wrote in message
news:47bc0353$1@newsgroups.borland.com...
> I use delphi 5,Indy 9.0.50
You said you were using the Indy development snapshot. You should have said
that it was the Indy *9* snapshot. That makes a big difference.
> No I am sure Tidpeerthread can not free clearly.
Are you using TIdThreadMgrDefault or TIdThreadMgrPool?
TIdThreadMgrDefault.ReleaseThread() does free the TIdPeerThread immediately.
TidThreadMgrPool.ReleaseThread(), on the other hand, puts the TIdPeerThread
into a queue for later reuse.
> Server.ThreadMgr.ReleaseThread(LThread); ---> Lthread is being free.
>
> destructor TIdThread.Destroy;---->Cleanup;---->calls
> ThreadMgr.ReleaseThread
>
> So this method is called twice.
Which is perfectly fine. ReleaseThread() is designed to handle that.
> but above code prevents any error.
It is not an error, though. Since Free() was already called on the
TIdPeerThread once, ReleaseThread() should not call Free() on it again.
Hense the check to see if the thread still exists in the list or not.
> I can not examine all indy code.But I want to find problem.
There is no problem in the code you have shown so far.
> For example tidtcpserver.maxconnections:=1 and one client is being
> connected.Other client try to connect and it is being prevented by indy.
> And thread counts of application increase.
As it should be since two TIdPeerThread objects are being created. But when
the second client is disconnected right away, the second TIdPeerThread is
freed as well, and the application's thread count should drop back to 1.
> And if I close the server application "destructor TIdThread.Destroy;"
> methods are being called twice.
The only way that can happen is if the second TIdPeerThread was not removed
from the TIdThreadMgr when the client was rejected.
Gambit
