Why is Thread.Name a write-once property?

Hot Topic

Where gets Intellisense the descriptions of methods, properties, ...????
Getting started with XML & serialization
Screenshot
I want to store the connection request and later on i will send the response to those requests using persistent connection.
Please help me develop a system utility using .net
A question on the new CLR Profiler for .NET Framework 2.0 Beta2
DataGridView msACCESS
Method Not found error in COM+
Where is the REFERENCE contstraint that causes the conflict?
GC.Collect() freezes for several seconds on gen 2 collection

.NET Development

Provider error while reading DBF file
What does MSI Stand for?
Problem running VS.NET 2005 Application from shared drive!
Change output date format in xmlserializer
Error 1053: The service did not respond to the start or control request in a timely fashion...
DAAB for Microsoft Access?
Source for Process.Start
RE
No connection could be made because the target machine actively refused it
I get an invalid character erorr when trying to access an asmx file from internet explorer

Why is Thread.Name a write-once property?

In my application, I have run into an InvalidOperationException when I did try to re-assign the Thread.Name property. Looking at the doc, it says that this property is write-once. Can someone tell me why For me this constraint is just annoying (the workaround is easy but painfull).

Thanks in advance,
Joannes

Answer this question

Why is Thread.Name a write-once property?

  • DLilga

    Thanks for your response. Actually, I did only encounter this limitation in setting-up a complicated grid computing testing suite framework. I admit that regular needs do not call for being able to change this property multiple time, nevertheless I see no real reason not to be able to.

    What if your current thread name has already been set by a library that you do not control What if this library systematically sets the thread name (for good or bad reason), why can't you change again the thread name

    Also following the logic of this restriction, why not prevent Thread.Name to be set after Start() is called. In you want to simplify the life of the debugger, it would make much more sense IMO.

    Nevertheless, I would greatly prefer to have the full liberty to set Thread.Name whenever I want (my responsability to make the debuggers life simple).

    Joannes

  • Shadi_05

    The Thread.Name property is primarily consumed by the profiling and debugging tools associated with the .NET Framework.  Setting this more than once during runtime may confuse said dependen cies.  Users may consume it as basically an associated piece of state with a thread.  Renaming a thread may be useful from a user perspective, but it's ultimately somewhat simple to associate a changeable name with a thread object without sacrificing this name-once invariant which our tools depend on.

    Dave

  • purpleton

    Why would you want to change the name multiple times   The Thread.Name is used as an identifier by debuggers allowing it to be change would cause debuggers to lose track of the thread.

  • hotwind

    Actually, there is no constraint (at least no constraint specified in the doc) about the time when the Thread.Name can be set. Therefore the Thread.Name can be set at any time (at the middle of its execution) and confuse whatever debugging tools that rely on it. Is there something that I have missed in your point

    IMO, many reasonable designs are possible:
    • Thread.Name is not writeable (name can be set through  constructor only).
    • Thread.Name is (freely) writeable before Thread.Start and not afterward.
    • Thread.Name is writeable at any time.
    Before of the situation described at the beginning of this post, I think that the current design of Thread.Name is hacky and does not even fits the purpose that you are evocating.

    Joannes
  • Why is Thread.Name a write-once property?
Answer this question