>> I think the thread name restriction comes from the fact that it's >> using the Win32 mechanism for thread naming, which involves a bizarre hack. Win32 threads don't really have names, but there is a convention by which you can throw a particular kind of SEH exception as a way of telling the debugger what you'd like your thread to be called!
You can "name" a thread any number of times by modifying its TIB... Then in the debugger, you can access the thread name like this: (char*)(DW(@TIB+0x14)) Google for "XTib" and you'll find it, no SEH is involved, only SEX :) Cheers, Stoyan -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Ian Griffiths Sent: Wednesday, October 20, 2004 8:06 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Theads.... System.Threading.Thread represents a logical .NET thread. And I *think* it's always a thread in your AppDomain. (The CLR does some slightly funky stuff with the marshalling of Thread objects when Win32 threads cross AppDomains, so it's possible that the same object might be visible in multiple AppDomains. This kind of cross-appdomain visibility is not generally available to normal objects, but certain .NET types get special treatment. I *think* it's Thread and String that are treated this way but I might be remembering it wrong.) A System.Threading.Thread will certainly never represent a thread outside of your process. A ProcessThread represents a thread that might be in a different process from yours. It represents a physical Win32 thread. So, the two main differences are the physical/logical distinction, and the in process/out of process distinction. (In VS.NET 2005, the mapping between physical Win32 and logical .NET threads is not one to one.) I think the thread name restriction comes from the fact that it's using the Win32 mechanism for thread naming, which involves a bizarre hack. Win32 threads don't really have names, but there is a convention by which you can throw a particular kind of SEH exception as a way of telling the debugger what you'd like your thread to be called! The essential problem with the mechanism is that you can't change the name of a thread. .NET inherits that restriction. -- Ian Griffiths - DevelopMentor http://www.interact-sw.co.uk/iangblog/ > -----Original Message----- > From: Hewitt, Simon C. (Contractor) > > Does anyone know the relationship between System.Threading.Thread and > System.Diagnostics.ProcessThread? > > I am trying to reconcile the number of threads shown in TaskManager for > a process with the threads shown in VS Debugger - ie which are mine and > which belong to the infrastructure/OS. > > I can iterate all the threads running in my process (using > System.Diagnostics.Process.GetCurrentProcess().Threads) but I can't > translate from ProcessThread to Thread so that I can find out whether it > is a TheadPool thread or not. > > For some reason, a Thread won't let you set its Name property if it > comes from the ThreadPool which would have helped! (Surely it could > reset the name back to null once the thread had finished?) =================================== This list is hosted by DevelopMentorR http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with CSharp August 30 - September 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with CSharp August 30 - September 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com
