> [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.
>
> I have created a wiki page to collect the information. Please DO NOT
reply
> to this message. Instead, please use [EMAIL PROTECTED] (so that
we
> have one open list) to discuss your ideas.
>
> PLEASE NOTE: In order for this information to have the most impact, Sun
> needs it by end of this week (October 29th). [The short time is not Sun's
> fault. They had asked earlier in the summer, but the ball got dropped. I
> just ran into the J2SE lead, who raised the issue again].
>
> --- 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]
