Reactive Streams utility API

[James Roper]

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 <pavel.rappo at oracle.com> wrote:

>
> > On 25 Sep 2018, at 05:33, James Roper <james at 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
>
>

-- 
*James Roper*
*Senior Developer, Office of the CTO*

Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>