Sounds good to me, I'll ping Viktor to make sure he sees it too. On Wed, 26 Sep 2018 at 06:34, Pavel Rappo <[email protected]> wrote:
> > > On 25 Sep 2018, at 05:33, James Roper <[email protected]> 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 > > -- *James Roper* *Senior Developer, Office of the CTO* Lightbend <https://www.lightbend.com/> – Build reactive apps! Twitter: @jroper <https://twitter.com/jroper>
