[concurrency-interest] Proposal for a CallerRunsExecutor in j.u.c.Executors

Luke Sandberg lukeisandberg at gmail.com
Fri May 23 20:05:40 EDT 2014

Guava has an Executor instance called

For Guava users it is very popular for passing to APIs like
ListenableFuture.addListener and other Executor accepting utilities for
when the task will be quick enough that it isn't worth submitting to a
thread pool.

There was recently a performance bug reported against it:

This led to us reconsider the implementation in Guava and then thinking
that maybe this should even be a j.u.c.Executors feature.

We haven't decided exactly what we want to do (and we are somewhat limited
by needing to consider current MoreExecutors.sameThreadExecutor() users)
but the current proposals are:

* deprecate/remove sameThreadExecutor from guava and replace it with two

  Returns a static final instance of
    new Executor() {
      public void execute(Runnable r) {
  which would be identical to the current sameThreadExecutor() (which
includes shutdown semantics)

* deprecate/remove sameThreadExecutor from guava and replace it with a
single method


Returns a shared ExecutorService (or really a ListeningExecutorService
since this is guava) instance, that cannot be shutdown and all the methods
return completed futures.

So there are still a lot of things up in the air, including the name!  But
we figured that the best place for a simple utility like this would
ultimately be in the JDK itself and we were interested in gathering the
opinions of the people on this list.

Our plan is still to make a change in Guava, but hopefully (with the input
from this list) it will be compatible with a later change to

I think the main questions to answer would be
* Is it worth having an ExecutorService instance of this or just an
Executor (or both)?
     In the Google codebase, the vast majority of the time it only needs to
be an Executor.  The cases where this is useful as an ExecutorService are
more common in testing situations, though occasionally you see it used to
essentially disable concurrency.
* If we do want to have an ExecutorService should it be shutdown-able, how
useful would that be?  would it be useful at all beyond testing scenarios?
* What should we call it?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140523/e79f8ea9/attachment.html>

More information about the Concurrency-interest mailing list