Do you name your Threads for debugging?

[Darian Miller 361]

I posted a blog article on this topic yesterday: https://www.ideasawakened.com/post/name-your-threads-even-the-ones-auto-created-by-delphi

 

I'm curious how many others do this sort of thing.  I think it really comes in handy sometimes.

 

I also went looking for the reasons behind each of the Delphi-created threads, other than the main message loop.  Do you have any info on that?  I could swear I read an article on it years ago, but couldn't find it.

[vfbb 285]

Darian, I name my threads/tasks with the status also (running, wait, canceled). But this is very slow, very, specially in mobile, I had to put a {$IFDEF USE_THREAD_NAME} to enable only when I need.

Edited April 16, 2020 by vfbb

[aehimself 396]

Yes, yes and yes. I have a custom TThread descendant, which sets it's own name to it's classname. Makes debugging a lot more easy than hunting for IDs.

[Lars Fosdal 1792]

Yes.  I use the thread class name and an instance id.

[Jacek Laskowski 57]

@Darian Miller Your code starting with initialization is not perfect, because it fires up before all native threads are created.

[Fr0sT.Brutal 900]

+1 for naming, it's handy. I do it manually though with just a class name

[dummzeuch 1505]

I wrote my own TThread class descendant which sets the name to the class name.

 

It also automatically sets the name "Main" for the main thread. (Don't the latest Delphi versions already do that?)

[Edwin Yip 154]

@Darian Miller, Thanks for sharing, but your code will pollute existing thread names such as "main thread" and "thread-created-by-madExcept". I'm not sure if there is a way to check if the thread's named already before changing its name?

[Darian Miller 361]

10 hours ago, Jacek Laskowski said:

@Darian Miller Your code starting with initialization is not perfect, because it fires up before all native threads are created.

I imagine it could certainly happen - but I haven't witnessed that I recall in any debugging session using this type of code over quite a few years. 

 

Do you have knowledge of all native threads created and what they are used for?

[Darian Miller 361]

8 hours ago, edwinyzh said:

@Darian Miller, Thanks for sharing, but your code will pollute existing thread names such as "main thread" and "thread-created-by-madExcept". I'm not sure if there is a way to check if the thread's named already before changing its name?

 

I don't know of any quick tricks to get the current thread name, perhaps someone will share that if it's available.

 

 

[Darian Miller 361]

I hadn't seen this yet - Set/Get thread description available since Windows 10 1607 (Anniversary Update) and Windows Server 2016

https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreaddescription

[Jacek Laskowski 57]

1 hour ago, Darian Miller said:

I imagine it could certainly happen - but I haven't witnessed that I recall in any debugging session using this type of code over quite a few years. 

 

Do you have knowledge of all native threads created and what they are used for? 

Unfortunatelly I don't.

 

When it comes to the order of starting the "initialization" section it's not always the same, it all depends on the uses section, in my case your code is launched before RTL/VCL threads.
I bypassed this problem by adding a anonymous thread with delay:

procedure NameDelphiThreads(const pMainThreadId : THandle);
begin
  TThread.CreateAnonymousThread(
                                procedure
                                var
                                  vSnapshot:THandle;
                                  vProcessId:THandle;
                                  vTE32:TThreadEntry32;
                                  i:Integer;
                                begin
                                  Sleep(100);
                                  vProcessId := GetCurrentProcessId();
                                  vSnapshot := CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, vProcessId);
                                  if vSnapshot <> INVALID_HANDLE_VALUE then
                                  begin
                                    [...]
                                  end; 
                                end
  ).Start;
end;

 

[Darian Miller 361]

4 minutes ago, Jacek Laskowski said:

When it comes to the order of starting the "initialization" section it's not always the same, it all depends on the uses section, in my case your code is launched before RTL/VCL threads.
I bypassed this problem by adding a anonymous thread with delay:

 

 

That works.  I actually started this code as part of some internal thread management plumbing that I'm building.  I separated it out for the blog article but I used something similar to it in an initialization section for at least a decade prior at a previous job.  I no longer have access to that code to know if it added any delays or other tweaks.  I doubt it did knowing that I wrote it a very long time ago.