0

At a low level, how is Reactive streams different than having a separate thread pool to work on tasks? (Supposedly that's the selling point of Reactive) Does stream use something else other than a thread pool for waiting on I/O?

Glide
  • 20,235
  • 26
  • 86
  • 135
  • Threadpools are either bounded and end up blocking, or unbounded and end up with resource exhasution which Ive been lead to believe reactive programming doesn't suffer from. However it can suffer from noisey neighbour in certain circumstances e.g. PaaS – Darren Forsythe Apr 12 '21 at 22:44
  • Thanks for your response. How can threadpools be unbounded and end up with resource exhaustion and reactive programming not that way? That link does not seem to answer the questions. – Glide Apr 12 '21 at 22:47
  • @Glide Whenever you switch between threads, the CPU has to perform a context switch - for a few threads switching occasionally this is barely noticeable, but when you hit hundreds, or thousands of threads the context switching becomes a massive overhead that cripples performance and (effectively) prevents your app from scaling further. Reactive programming on the other hand only (generally) maintains a single event loop thread, and instead works by callbacks to that one thread - so no context switching is necessary, even with tens of thousands of open connections. – Michael Berry Apr 13 '21 at 08:06
  • @MichaelBerry that's a good point. After researching, I think the main difference in the Reactive Event Loop is that it takes advantage of the operating system's nio feature of "channels" - as opposed to threads - for reading requests. Channels does not block any threads while it's waiting reading the "stream" of incoming data – Glide Apr 13 '21 at 21:47

0 Answers0