Why do I need this as I am in the thread already you ask? Because I use a generic ThreadPoolManager class that basically pools all sorts of different possible operations and I want to be able to add some sort of identifier to the thread so later I can look at the pool and see how many threads of a particular operation are being executed. The thread pool class interface has an initialize method that runs first and so in that method, I want to get the current thread and add the identifier.
I’m assuming that in a running thread, calling app.CurrentThread will indeed always return the thread I am running in. Or so you would think, but I just want to be sure…
It will return nil for the main thread, but otherwise, yes, the thread you’re in.
Instead of a pool manager, in this case it sounds like you just need a Thread subclass that does the initialization you want in either its Constructor or in the Run event. Just an alternate idea to consider.
I really want to stick with the pool manager as I could potentially have a very large number of threads to execute and the pool manager does a very nice job of queuing up a certain number of threads to execute at a time instead of having all the threads running at once. I’ve built this architecture into many aspects of my code.
Until now, I would just queue up the items and let them run in the background as that’s truly what they were. But now I am in a situation where I need to know when a set of specific threads are done so I can update the UI and enable controls. Adding an identifier to the threads and then using a timer to scan the pool periodically and see how many of a particular identifier are running is really what I need so that I can tell when all my operations are done.
You are right. But that doesn’t tell me the sort of operation I am doing. The ThreadPoolPool class is a completely polymorphic class. It takes a “WorkItem” which is a class interface and adds that item to a pool of threads. It then executes the methods of that WorkItem class interface. So I need to be able to specifically know what each WorkItem is doing. The thread ID does not tell me that.
I thought about that. But the ThreadPool class interface already has an initialize method it runs and that’s the perfect spot to insert this identifier. I’ve got it figured out and pretty happy with it…
Yeah, I just ran this for the first time after coding it. Worked great. And thanks to the Auto class, the “tags” I apply to the threads can be anything.