Re: ForkJoin refresh

On 2/5/20 10:15 AM, Peter Levart wrote:

> 
> Would something like the following be more "precise" in targeting the 
> task and only the task and not any other code that executes after the 
> task in the same thread? At least stray interrupts would not be possible 
> as a consequence of cancel(true) for some unrelated task. Should anyone 
> interrupt the pool thread outside of normal task execution, the 
> interrupted status would not propagate to task code nor would it be lost 
> after the task has finished.
> 

Thanks for taking a look at this. I'm not sure your suggested changes
are preferable though. Interrupt status for interruptible tasks is
cleared at end, before running next task, which reduces the impact of
other slow threads needlessly interrupting the task. I can't think of
cases where it helps to conditionalize this on whether any occurred?
To better explain though, I'll add to internal documentation that the
only occurrence of Thread.interrupt inside FJ code itself is during
termination, in which case tasks are or will be cancelled anyway.

-Doug

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest