Although this enhancement to java.lang.Thread has not been shouted down, I have not heard any other comments, either. It proposes (1) a built-in orderly way to inform a thread to terminate itself and (2) a way to contol suspend/resume of a thread.
All critique is welcome. Dan Lydick > > > [Original Message] > > From: Noel J. Bergman <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > > Date: 10/25/04 10:19:05 AM > > Subject: Sun wants Apache input on JDK futures > > > > Sun is the final stages of collecting requirements for the releases that > > will follow Tiger, which means the next 3 years. So here's your chance to > > tell Sun what you would like to see in J2SE versions 6 and 7. Once we > > gather all of the ideas, we can try to see if we can prioritize the list. > > ...snip... > > > > --- Noel > > > My $0.02 worth, having just gotten started w/ JDK 1.5, but don't > see these related features available: > > 1. The new java.lang.Thread.State class adds the capability to determine > the current state of a given java.lang.Thread. However, the Thread > class also needs to have a built-in equivalent to a mechanism that > must currently be supplied by the user. In the bad old days, > you used Thread.stop() to kill a thread. However, that would leave > resource locks in place. Therefore, the common wisdom became for > the user to declare a boolean that the thread could periodically poll > and shut itself down in an ordered fashion after releasing resource > locks and any other cleanup. > > I would like to see a mechanism built into java.lang.Thread that would > to this on a language-wide basis. Perhaps a method with a parameter > called 'Thread.setRequestedState(Thread.State reqState)' where a > shutdown > would call 'Thread.setRequestedState(Thread.State.TERMINATED)'. When > that > thread polls the requested state value (perhaps using a 'private > ThreadState > requestedState') using a method 'Thread.getRequestedState()', then it > could > initiate its shutdown sequence. > > 2. This is similar to the suggestion from Stefano Mazzocchi about > suspending a thread and resuming. In this case, a thread could > be suspended by doing a 'Thread.setRequestedState(Thread.State.WAITING)' > followed by an un-suspend with > 'Thread.setRequestedState(Thread.State.RUNNABLE)'. > This would be functionally equivalent to Thread.notify()/notifyAll(), > but > would be thread-specific, not setting the state of some random thread or > all threads. I say that is a syntactic improvement because > Thread.notify() > never tells the casual reader what thread will be made RUNNABLE again, > even > if there is only one possible thread that could get so marked. > > The full prototypes would be, for get req state: > Thread.State getRequestedState() > boolean setRequestedState(Thread.State newState) throws > IllegalArgumentException > > When setRequestedState() succeeded, it would return 'true'. If it could > not set that state, it would return 'false'. If anything but > TERMINIATED, > WAITING, or RUNNABLE were requested, it would throw > IllegalArgumentException. > > Notice the distinct resemblance to '(Thread.State) Thread.getState()'. > This returned the _current_ state, where the above discussion sets and > gets the _requested_ state. Notice that, again refering to Mr. > Mazzocchi's > post, this approach would also work with JNI. All that is required is > for the JVM to accept the requested states TERMINATED, WAITING, and > RUNNABLE. > > > > Dan Lydick > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
