Moving even more to the fringes of the scope, I think there is a definite need for a fixed thread ID (of type int?) to be available in java.lang.Thread (so perhaps a method "int getID()" . The concept of a mutable "thread name" isn't helpful when the particular thread in which something occurred needs to be determinately known.
As a simple example, some app servers name all their worker threads identically. Without resorting to something like log4j's "nested diagnostic context", you can't associate log entries with the thread in which they occurred using Thread.getName().
FWIW...
Donnie
>>> Bill Pugh <pugh@cs.umd.edu> 08/22/01 12:05PM >>>
Although this is at the margins of the scope of JSR 133, I'd like to
open it up for discussion.
The isAlive method of java.lang.Thread returns true if the Thread has
started but has not yet terminated.
It seems to be that programs need to have a way of figuring out:
* has a thread started
* has a thread terminated
You can fake a way to see if a thread has terminated by doing a join
with an immediate time-out, but that is rather clumsy.
Should we consider adding a hasStarted or isTerminated method to
java.lang.Thread?
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:34 EDT