At 12:20 PM 18/11/2003, Doug Lea wrote:
> >
> > 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.
> 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?
In case (1) whether or not it is necessary would depend on what the
consequences are of continuing until the next checkpoint. I imagine that
some scenarios require the test for interruption, and others don't, so I
can neither disagree nor agree.
As for case (2) I can't think of a use case off hand either, but that
doesn't mean that one doesn't exist.
During earlier discussions it became apparent that giving priority to
interrupt(), but avoiding lost notificiations, seems to involve not just
spurious notifications, but the internal invocation of notifyAll(). This
latter could be quiet expensive when there are many threads waiting.
At the moment, adopting (or rather retaining) the simpler spec looks to me
to be the better option.
Sylvia.
-------------------------------
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