[concurrency-interest] ThreadPoolExecutor - cancel rejected tasks with Discard*Policy?

Doug Lea dl at cs.oswego.edu
Wed Feb 12 09:26:25 EST 2020


On 2/12/20 5:01 AM, Petr Janeček via Concurrency-interest wrote:

> // The following task will get rejected and discarded by the pool:
> executor.submit(task).get();
> ```
> 
> The code above will block forever, the `get()` call never returns. The task
> had been rejected, but the returned Future is not cancelled, will never run,
> and therefore will never be completed in any way. There's no way I'm aware
> of to know the returned Future had been rejected.

Right. None of the supplied RejectedExecutionHandlers perform
task.cancel when discarding. In retrospect, they probably should have.
At this point, it would probably suffice to add discussion to javadocs
about how to do so. But if others support adding new Policies, we should
consider it.

-Doug

> 
> This was very confusing and unexpected to me, I definitely expected the policy
> to cancel the task. Note that this only happens with the Discard* policies
> because the AbortPolicy throws and never returns a broken Future to the user,
> while the CallerRunsPolicy returns a runnable Future.
> 
> I'd like to open a discussion around a few possible naive approaches to ease
> the pain of future developers who get similarly caught by surprise:
> 
> 1. Change the Discard*Policy to cancel the task. I did not find any place
> where this would break any existing contracts. That said, obviously such
> a change changes the behaviour in a significant way, and so it might not be
> the way to go.
> 
> 2. Introduce a DiscardAndCancelPolicy. Yes, writing such a policy is trivial
> and anybody can do it if he needs it. The problem is that this is so obscure
> that I cannot imagine many people do this right away. Discoverability is very
> important here, and having an extra policy would tip people off.
> 
> 3. Change the Discard*Policie's JavaDoc in a way it is clear that it does not
> play with ExecutorService.submit() very well.
> 
> 4. All of the above, or some more complex solution?
> 
> Thank you,
> Petr Janeček
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 




More information about the Concurrency-interest mailing list