by jmansion » 26 Apr 2007, 10:14
> Mostly because it's not thread safe (i.e., multiple threads calling setName() simultaneously (or simultaneous read/write access) will cause havoc...)
I think that's lame! ;-)
1) It could be made thread safe.
2) Normally the use case is that the thread wants to change its own name, because of the context it is executing in.
Essentially I'm writing a different thread pool implementation. The current ThreadPool is only able to change the name using a friend, which indicates to me that there is a requirement and its hacked.
I think the underlying requirement is for something that represents (to a human) what the thread's activity (small 'a') is. And by convention to match Java, CLR etc we provide 'thread name' for that, as a special-case thread local in effect. But its not really the thread that needs a name (it has a handle for identity) its something that represents the binding of the thread to its current activity.
There ways to represent this other than via thread name, but that's the way that ThreadPool does it and it does follow existing practice.
