-
Bug
-
Resolution: Fixed
-
P4
-
6
-
b51
-
generic
-
generic
Tim Peierls wrote:
Doug Lea wrote:
>>>> We don't want an interrupt occurring before the task starts to cancel
>>>> the task, since that interrupt might have been targeted to the
>>>> previous task run by that thread. This would be much much worse.
>>>>
>>>> So instead, the runState == STOP test is taken as a commit point. The
>>>> down side is that there is a window during which our best efforts to
>>>> stop things fail. I don't think there is a solution to this. Or does
>>>> anyone see one?
David Holmes wrote:
>> Surely if you invoke Thread.interrupted before checking the runState you
>> will have cleared any prior interrupt that may have been targeted at
>> the previous task? Any subsequent interrupt is either due to the
>> shutdownNow or specific cancellation of this task.
Just to make sure we're talking about the same thing -- I was asking
whether the current TPE.runTask(),
runLock.lock();
try {
// Abort now if immediate cancel. Otherwise, we have
// committed to run this task.
if (runState == STOP)
return;
Thread.interrupted(); // clear interrupt status on entry
... run task ...
} finally {
runLock.unlock();
}
might be improved (perhaps only slightly) as follows:
runLock.lock();
try {
Thread.interrupted(); // clear interrupt status on entry
// Abort now if immediate cancel. Otherwise, we have
// committed to run this task.
if (runState == STOP)
return;
... run task ...
} finally {
runLock.unlock();
}
--tim
-------------------------------------------------
David Holmes replied:
Yep that is still what I am referring to. The call to interrupted should
clear any outstanding interrupts for the previous task, or a current
interrupt due to a shutdownNow. In the latter case the testing of runState
covers things so it is okay to clear the interrupt.
David
-------------------------------------------------
Doug Lea responded:
You are right. Thanks! Will do.
###@###.### 2005-03-30 09:25:33 GMT
Doug Lea wrote:
>>>> We don't want an interrupt occurring before the task starts to cancel
>>>> the task, since that interrupt might have been targeted to the
>>>> previous task run by that thread. This would be much much worse.
>>>>
>>>> So instead, the runState == STOP test is taken as a commit point. The
>>>> down side is that there is a window during which our best efforts to
>>>> stop things fail. I don't think there is a solution to this. Or does
>>>> anyone see one?
David Holmes wrote:
>> Surely if you invoke Thread.interrupted before checking the runState you
>> will have cleared any prior interrupt that may have been targeted at
>> the previous task? Any subsequent interrupt is either due to the
>> shutdownNow or specific cancellation of this task.
Just to make sure we're talking about the same thing -- I was asking
whether the current TPE.runTask(),
runLock.lock();
try {
// Abort now if immediate cancel. Otherwise, we have
// committed to run this task.
if (runState == STOP)
return;
Thread.interrupted(); // clear interrupt status on entry
... run task ...
} finally {
runLock.unlock();
}
might be improved (perhaps only slightly) as follows:
runLock.lock();
try {
Thread.interrupted(); // clear interrupt status on entry
// Abort now if immediate cancel. Otherwise, we have
// committed to run this task.
if (runState == STOP)
return;
... run task ...
} finally {
runLock.unlock();
}
--tim
-------------------------------------------------
David Holmes replied:
Yep that is still what I am referring to. The call to interrupted should
clear any outstanding interrupts for the previous task, or a current
interrupt due to a shutdownNow. In the latter case the testing of runState
covers things so it is okay to clear the interrupt.
David
-------------------------------------------------
Doug Lea responded:
You are right. Thanks! Will do.
###@###.### 2005-03-30 09:25:33 GMT