On 01/24/12 02:46 AM, David Holmes wrote:
Hi Chris,
Hard to evaluate a completely new design like this as the devil is
always in the details.
I don't understand the purpose of handlePossibleCancellationInterrupt.
Given it doesn't clear the interrupt state why does it need to wait?
Yes, this is true. I can't see any need for it to wait now since it
doesn't clear the threads interrupt state. I felt this was more of a
marker/place holder to determine the correct course of action here.
That said, the previous implementation did not attempt to clear the
threads interrupt state either. If Doug agrees that this code is
unlikely to every be reinstated, then I think it can probably be removed.
-Chris.
Otherwise it looks okay.
Thanks,
David
On 24/01/2012 1:26 AM, Chris Hegarty wrote:
This issue was raised on the jdk7u-dev mailing list [1].
The change is to update the FutureTask implementation to what is in
Doug's CVS. The old implementation using AbstractQueuedSynchronizer is
replaced with a control "state" field that is updated by CAS to track
completion, along with a Treiber stack to hold waiting threads.
http://cr.openjdk.java.net/~chegar/7132378/webrev.00/webrev/
I have already reviewed this change. The diffs in the webrev are not all
that useful, I reviewed it by going through the new file.
Doug,
I added a new test for this. It fails about 1 in every 3-4 runs on some
of the boxes I have access to. Is this useful? Would you want to take it
into your CVS?
-Chris.
[1]
http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-January/001439.html
