When a server performs a managed disconnect, TidTelnet now notices and fires
the onDisconnected event. This is more than happened with 9.0.14, where you
had to trap the exception from the read thread to detect
EconnClosedGracefully & post a message to have the main thread call
disconnect.
With 9.0.18, however, after a server-disconnect the internal 'connected'
state is set to false but, unfortunately, the read thread is not shut down.
Sunsequent attempts to close the app will fail because of the
'waitAllTerminated' finalization in TidThread.
Also, one thread leaks every time this happens. After three successuful
connects and three server disconnects, the GThreadCount in the
waitAllTerminated is up to three.
Once one thread has leaked, the app will not shut down no matter what
happens. The use can click on their 'Disconnect' button & call disconnect
as many times as they want but only the current read thread is terminated if
it is flagged as connected. The leaked thread/s still lurk around in the
GThreadLock lockList to stop your app closedown dead.
The workaround is to always call 'disconnect' when 'disconnected' and ignore
any connected' state, because it lies. ie
'if myTelnet.connected then myTelnet.disconnect;'
which is what users tend to code up in onClose handlers and the like, will
lead to app close fails.
Rgds,
Martin
PS Indy 10 TidTelnet is still unuseable, as of yesterday, because of the
100% CPU bug.
PPs why is 'Telnet' so esy to mis-type as 'Telent'?
