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

Petr Janeček JanecekPetr at seznam.cz
Wed Feb 12 05:01:37 EST 2020


I'm sorry to open a new thread on something I feel must have been discussed before,
I did not find any previous mention.

Imagine this:

// Note the DiscardPolicy
ExecutorService executor = new ThreadPoolExecutor(
1, 1,
1, TimeUnit.MINUTES,
new ArrayBlockingQueue<>(1),
new ThreadPoolExecutor.DiscardPolicy()

Runnable task = () -> Uninterruptibles.sleepUninterruptibly(1, TimeUnit.SECONDS);
// The following task will get rejected and discarded by the pool:

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.

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

More information about the Concurrency-interest mailing list