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]>




> > 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

> > 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

> > 

> > 

> > --- 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

>     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

>     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

>     not set that state, it would return 'false'.  If anything but


>     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





> Dan Lydick


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to