Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Equivalent of PublishOn, SubscribeOn, Work-Stealing/Drain-loop, Scheduler - Controlling which thread callback runs on #127

Open
hutchig opened this issue Oct 9, 2019 · 1 comment
Milestone

Comments

@hutchig
Copy link
Contributor

hutchig commented Oct 9, 2019

When looking at the issue of multiple Subscribers a topic that came up was
a nested

onNext(
   onNext(
      onNext(

stack.

Problem: As onNext cannot be called more than once there is only one data payload traversing the stream.

However the 'obvious' solution is for onNext to return early having kicked off
some concurrent work on a different thread to complete a CompletionStage when
done.

A downside of this is that a payload will switch threads as it moves through each
onData layer (as onNext has to return the calling thread to the caller).

See https://youtu.be/hfupNIxzNP4?t=1872 for intro.

To get the best of both worlds we need the ability to influence the thread used
for the processing of a stage.

I am not sure what milestone this is best done for but wanted a place (here) to discuss.

@cescoffier
Copy link
Contributor

It depends on your execution model. Using an event loop model will always go back to the same context, avoiding the switch.

@Emily-Jiang Emily-Jiang added this to the Future milestone Jul 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants