Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
System.Threading.Thread.Name is a write-once property. I can assign to it at once, and only then if no other assignment has been made by application or library code. I am writing a multi-threaded event-driven application and would very much like to be able to change the name of the currently executing thread depending on the task its performing at the time.
Does anyone know why this has to be so, or is this a (wrong) presumption on the part of the CLR’s designers?
I found this old blog post saying that it’s for consistency.
In my opinion it should be changed back to be settable as much as we like, for the exact scenario you described. When using the thread pool I’ll be glad to have a name set for the current task to differentiate easily between those ten paused threads in the debugger.