[concurrency-interest] Proposal for a CallerRunsExecutor in j.u.c.Executors
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
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?
> On Sat, May 24, 2014 at 3:15 PM, Luke Sandberg <lukeisandberg at gmail.com>
>> 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
>>>> 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
>>>> There was recently a performance bug reported against it:
>>>> This led to us reconsider the implementation in Guava and then thinking
>>>> 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/
>>> 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
>> As for ThreadPerTaskExecutor, that name seems reasonable to me.
>>>> which would be identical to the current sameThreadExecutor()
>>>> 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.
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest