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

Martin Buchholz martinrb at google.com
Mon Jun 23 18:39:47 EDT 2014

So ... as usual, the best is the enemy of the good.

None of the current methods in Executors returns "just" an Executor - they
always return at least an ExecutorService.
While defining an Executor is easy, there are questions about defining an
ExecutorService, especially around life cycle management.  I think we
should define a static "system" caller-runs ExecutorService that is an
analogue of the common fork join pool - it cannot be shutdown and persists
to the end of the JVM's lifetime.  The uncomfortable questions are what to
do about calls to shutdown() and and awaitTermination() - we do not want to
keep track of currently active tasks to await quiescence.  We could have
awaitTermination hang until timeout elapses, or return immediately, or
throw UOE.

Since introducing a plain Executor is much better than doing nothing, let's
start with that.

On Fri, Jun 6, 2014 at 9:17 AM, Luke Sandberg <lukeisandberg at gmail.com>

> ping.  Is there anything i can do to help move this forward?
> Thanks,
> Luke
> On Sat, May 24, 2014 at 3:15 PM, Luke Sandberg <lukeisandberg at gmail.com>
> wrote:
>> On Sat, May 24, 2014 at 11:03 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>>> On 05/23/2014 08:05 PM, Luke Sandberg wrote:
>>>> Guava has an Executor instance called MoreExecutors.sameThreadExecutor
>>>> <http://docs.guava-libraries.googlecode.com/git/javadoc/
>>>> com/google/common/util/concurrent/MoreExecutors.html#
>>>> sameThreadExecutor()>
>>>> 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:
>>>> https://code.google.com/p/guava-libraries/issues/detail?id=1734
>>>> This led to us reconsider the implementation in Guava and then thinking
>>>> that
>>>> maybe this should even be a j.u.c.Executors feature.
>>> The class has been sitting there under the name DirectExecutor
>>> since JDK5 as a code example in the Executors javadoc.
>>> (See http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/
>>> concurrent/Executor.html)
>>> We even discussed putting it (as well as the other code example,
>>> ThreadPerTaskExecutor) in Executors but for some reason decided
>>> they weren't important enough. But they are important in that
>>> standardizing their names and usage will save people work.
>>> So I can't think of a reason not to do this, even if a decade
>>> too late for most purposes. Any objections to using these names?
>> Yeah we noticed the DirectExecutor example too, but consensus appeared to
>> be against using that name.  Also it was noted that in JCIP Brian Goetz
>> calls the same thing 'WithinThreadExecutor'.  callerRunsExecutor was
>> suggested due to the existence of ThreadPoolExecutor.CallerRunsPolicy. (And
>> there were about 10 thousand other suggestions: immediateExecutor,
>> currentThreadExecutor, synchronousExecutor,...).
>> I have no objection to DirectExecutor though I do have a preference for
>> CallerRunsExecutor.
>> As for ThreadPerTaskExecutor, that name seems reasonable to me.
>>>      MoreExecutors.newCallerRunsExecutorService():
>>>>        which would be identical to the current sameThreadExecutor()
>>>> (which
>>>>     includes shutdown semantics)
>>> I gather that this one uses a Lock just to support the
>>> awaitTermination method? (Otherwise it would need only
>>> a volatile boolean shutdown bit.) It does seem like a niche usage,
>>> but maybe someone could make a case for including it.
>> That is correct.  I agree that this is less commonly useful (and it is
>> often most useful in testing situations).  So just leaving this in Guava
>> could make sense.  Martin Buchholz suggested just making the
>> CallerRunsExecutor be a unshutdownable shared ExecutorService instance as a
>> kind of compromise.
>>> -Doug
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140623/71d26bdf/attachment.html>

More information about the Concurrency-interest mailing list