> On 25 Sep 2018, at 05:33, James Roper <ja...@lightbend.com> 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). -Pavel
