Proactor Pattern

[Suminda Dharmasena]

Quick question:

When a thread pool is used for dispatch does this boil down to the Proactor Pattern?

[Jon Brisbin]

On Wednesday, November 20, 2013 at 2:45 AM, Suminda Dharmasena wrote:

Quick question:

When a thread pool is used for dispatch does this boil down to the Proactor Pattern?

Actually, I'd say Reactor uses the Proactor pattern most of the time. We're very promiscuous with our design patterns. :)

But that's a good way to look at it. You can stop there, of course, but you don't have to. You can continue on in the spectrum and implement Reactor-ish patterns as well as Observable patterns, etc...

Thanks!

Jon Brisbin | Reactor Project Lead

http://about.me/jbrisbin | @j_brisbin

[Jernej Jerin]

I agree that this is a good question. Currently I am reading Chapter 3: Event Handling Patterns in book Pattern-Oriented Software Architecture, Patterns for Concurrent and Networked Objects, Volume 2 where both of these two patterns are explained. I also read the original papers for Reactor pattern and Proactor pattern. But I am a bit confused after reading the blog post for Reactor library and your statement here about actually using Proactor pattern (btw, why is not the library then called Proactor?). The following statements are from the Proactor pattern paper:

Web servers designed using a proactive event dispatching model handle the completion of asynchronous operations with one or more threads of control.

The OS then performs the operation on behalf of the Web server and subsequently queues the result in a well-known location.

The primary advantage of using the Proactor pattern is that multiple concurrent operations can be started and can run in parallel without necessarily requiring the application to have multiple threads.

If I understand correctly from this statements combined with open poster question about using thread pool, it implies that using thread pool does not mean Reactive pattern. So if we use explicit thread pool, we are not leveraging OS/kernel level threads, right? Or should I look at this Reactor foundational framework as a layer between JVM and my application logic, which would mean that we actually are not using explicit thread control in our application logic? But does that mean that using thread pool in Reactor framework, we are actually doing asynchronous calls to OS supported threads? I don't know a lot about JVM threads, but how is this even supported on JVM? As you can see I am quite confused now after reading all this sources.

Also in the paper for the Proactor pattern, when evaluating Reactor pattern, the following disadvantage is specified:

Lack of OS support for multithreading: Most operating systems implement the reactive dispatching model through the select system call [7]. However, select does not allow more than one thread to wait in the event loop on the same descriptor set. This makes the reactive model unsuitable for high-performance applications since it does not utilize hardware parallelism effectively.

Given the age of the paper is this statement still relevant. However if I look at for example node.js, it also uses only single thread for event loop. Why would that be inefficient, if we can then utilize threads in event handlers?