At 05:20 PM 11/17/2003, Doug Lea wrote:
> > So the only tangible benefit of attaching a higher priority to interrupt()
> > is that the programmer who is concerned to get maximally fast response to
> > interrupt() (and doesn't care about lost notifications) does not have
> to add
> >
> > if(Thread.interrupted()) throw InterruptedException;
> >
> > immediately after the call to wait.
>
>OK, but:
>
> 1. Anyone dealing with cancellation will find that they need to do this.
If cancellation is something I need to consider, then I need to be sure
that I don't have any long running loops that don't check for
Thread.interrupted. The check needs to be there and it doesn't have to be
immediately after the call to wait.
Perhaps the concern is the behavior of wait when the thread has been
interrupted. I've never seen a clear statement of that, but it has always
been my assumption that wait would throw an InterruptedException
immediately in that case. So
while ( foo.wait() ) {
... ; // something short
}
does not need any explicit check of Thread.interrupted().
> 2. I don't know of a use case where anyone needs to know whether a
> thread was notified before it was interrupted.
>
>Do you disagree?
>Or do you agree but still think we should adopt the simpler-looking spec?
>
>-Doug
>
>
>
>
>-------------------------------
>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:54 EDT