"Turboz" <turboz@turboz.moved.in> wrote in message
news:459c3f02@newsgroups.borland.com...
> If I can use AThread.Data to recognise users, how is simply
> identifying the AThread bad?
That is not what I said. Using the thread pointer itself as an
identifier is bad. Using the members of the thread object is not
(except of the the ThreadID, that is).
The Data property is only valid for the lifetime of the connection.
When a client disconnects, regardless of whether the thread is being
pooled or not, the thread still cleans up after itself, including
freeing any object that is currently assigned to the Data property.
That way, each client starts with a blank slate if the thread was
obtained from a pool.
> Data is a Property of the AThread so presumably (correct me if I am
> wrong) it would still identify the very exact same thread/property
which
> ever I use to identify my users?
No, it would not. You would assign a different object to the Data
property each time a new client connects, and then remove/free the
object when the client disconnects.
> Oh and FYI, I am using TIdThreadManagerDefault.
Then no pooling is being used at all.
> I did once look at using a TList and the Threads.LockList thing but
I had
> a problem in that I also needed to keep track of offline clients in
the same
> place
Thee is no problem doing that. Simply include a flag for each item
that indicates whether the client is connected or not.
> an array and not a threadlist of active threads.
I never said to use a ThreadList of active threads for your tracking.
> If you have a better idea please let me know!
A better idea for what exactly? What are you trying to track in the
first place?
Gambit
