Reactive Streams utility API

Pavel Rappo pavel.rappo at
Tue Sep 25 20:34:22 UTC 2018

> On 25 Sep 2018, at 05:33, James Roper <james at> wrote:
> Hi Pavel,
> <snip>
> As for the MutexExecutor itself, that was mostly written by Viktor Klang, and I believe he wrote it based on his experience implementing similar constructs for Akka mailboxes. There is one major problem with it that I'm aware of - it's not fair on the underlying executor. If you submit tasks at an equal or higher rate than can be processed by a single thread, the executor will never return the thread it uses to the underlying executor. I don't think that's hard to fix - we could limit the number of sequential tasks it does on a thread before resubmitting to the underlying executor.
> A slightly different incarnation of this problem is when each task invoked resubmits another task, for example, using the current reactive streams API, if I did ReactiveStreams.generate(() -> "foo").forEach(System.out::println), that is by design effectively an infinite loop that prints out foo, but being an asynchronous API it shouldn't actually be an infinite loop, it should return the thread back to the underlying executor at least periodically to allow that thread to be used for other tasks queued on the executor, but it doesn't do that.
> But this issue (and some similar issues that may exist) we haven't begun to consider addressing, primarily because fixing it requires selecting some magic numbers for limits on work to do, and they can't be selected without some realistic benchmarks being created to tune them to, and we're just not ready to take this implementation to that level, it could change very significantly which would change all the assumptions before it's ready to be used.

James, thanks for such a detailed explanation! Right now I'm mostly interested
in mechanics of this executor. I think this discussion deserves a separate
thread on concurrency-interest mailing list. What do you think? Once I've
started the thread there, I will get get back here with the link to it
(for the interested parties' convenience).


More information about the core-libs-dev mailing list