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
Sorry for delay; swamped...
On 01/24/12 06:00, Chris Hegarty wrote:
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
On 25/01/2012 4:56 AM, Doug Lea wrote:
Sorry for delay; swamped...
On 01/24/12 06:00, Chris Hegarty wrote:
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
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
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?
Otherwise it looks okay.
Thanks,
David
On