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
|