"Turboz" <turboz@turboz.moved.in> wrote in message
news:459c2421@newsgroups.borland.com...
> I am building a server which identifies users by their AThread
(Looping
> through an array of records to find a matching TIdPeerThread and
then
> obtaining the user name associated with it).
That is not a good way to identify users, even in Indy 8. You should
be using your own custom tracking information. You can use the
TIdPeerThread.Data property to associate your data with individual
threads if you want, but you should not be tracking the threads
themselves. Add your own tracking data to a list in the server's
OnConnect event, and clear it from the list in the OnDisconnect event.
If you need to find a TIdPeerThread instance, you can loop through the
server's Threads list, look for the Data that matches what you are
looking for. This way, it doesn't matter what the server does with the
threads, and your code will be easier to port to later versions.
> However recently something sprung to my memory about the Indy
> Threadmanager pooling AThreads.
All the more reson to change how you are tracking users in the first
place.
> So, I was wondering if someone could explain in fairly easy to
> understand terms, what the thread manager actually does
That is a little complex to answer, actually. It really depends on
WHICH thread manager you are using. Indy has 2 available.
One manager, TIdThreadMgrDefault, creates a new thread when a client
connections, and then destroys the thread when the client disconnects.
The other manager, TIdThreadMgrPool, stores idle threads in a list.
When a client connects, if there is an idle thread available, that
thread is associated with the new client and then resumed. Otherwise
a new thread is created. Either way, when the client disconnects, the
thread is paused and then put back into the list for later reuse if
the list has room, otherwise the thread is destroyed.
> is it actually safe to identify the unique user by their AThread?
No, it is not, especially when pooling is involved.
Gambit
