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

Luke Sandberg lukeisandberg at gmail.com
Fri Jun 6 12:17:36 EDT 2014


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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140606/14f8cb07/attachment.html>


More information about the Concurrency-interest mailing list