j.u.s.Stream and Fiber

[Arkadiusz Gasiński]

I actually meant (a) when I started this thread, but I think (b) is the
next question to ask if we (I mean you :)) want to ever consider running
parallel streams in fibers.

The use case that made me start this thread was: what would happen if I
start processing a large number of files in a parallel stream in the
context of a Fiber? I've finally found some time to check it and now I know
that (at least in the current prototype) some processing will be done in
the context of the fiber that triggered terminal operation on the pipeline,
but most work will actually be performed by ForkJoinPool.commonPool
workers. I have to admit that I was a bit surprised by this - not saying
this is good or bad, but for some weird reason was expecting all processing
to be done in the context of fiber(s).

Arek



On Thu, Sep 19, 2019 at 6:18 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> I think what’s being asked for here is the ability to ask (a) that
> parallel execution happen in fibers instead of raw FJ tasks and (b)
> adjusting the split/run choices to something more suited to IO-parallel
> rather than data-parallel operations.
>
>
>
> Sent from my MacBook Wheel
>
> > On Sep 19, 2019, at 4:25 AM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
> >
> >> On 18/09/2019 21:37, Arkadiusz Gasiński wrote:
> >> Hi,
> >>
> >> Sorry if this was asked already - looked through the mailing list, but
> >> couldn't find the answer... And the question is: Are JDK's j.u.s.Stream
> >> implementation classes Fiber-aware? For example if I trigger a terminal
> >> operation on a parallel stream in the context of a Fiber, would there
> >> possibly be new fibers scheduled to process the stream elements? If so,
> >> what will be the scope of these additional Fibers?
> > If there is parallel execution then it will use ForkJoinPool, no change.
> It's possible that the fiber executing the terminal operation may
> temporarily pin its carrier thread when joining (you might see it blocked
> in externalAwaitDone). I'm sure Doug or Martin will have ideas if it
> becomes an issue.
> >
> > -Alan
> >
> >
>
>