As far as I can tell from the docs, there is no way the app can ascertain which threads have been created - is this correct? I can of course keep a note of threads myself as they are created (such as a dictionary with threadID as key and thread pointers as values) and terminate. That would allow them to be inspected by code at any time (that is, not using the debugger).
I have a case in my app where (on one Mac Mini here but not mine), after being woken up from overnight sleep there was a thread running but it is stuck somehow, and I’d like to be able to inspect thread states.
I was having issue with laptops waking from sleep and not gaining network access for 10 seconds. Now I check for internet access if I can’t connect to my database.
Also I cancel and reset all Timers on waking as they seem to cache while asleep.
In the end I’ve kept a list of tasks in a dictionary - each task adds itself to and removes itself from this dictionary. Added an item on the app’s debug menu to bring up a nice little window to list all the running tasks. That uses a task to do the work and refreshes itself every 250 msec - so there’s always one task in the list.
Now to put a copy of this on SWMBO’s Mini and see what’s going on with the task that gets wedged.
[quote=407851:@Tim Streater]In the end I’ve kept a list of tasks in a dictionary - each task adds itself to and removes itself from this dictionary. Added an item on the app’s debug menu to bring up a nice little window to list all the running tasks. That uses a task to do the work and refreshes itself every 250 msec - so there’s always one task in the list.
Now to put a copy of this on SWMBO’s Mini and see what’s going on with the task that gets wedged.[/quote]
Perhaps you’d like to take a look at “Creating a thread pool” from Aaron Ballman: