Thread pool

The thread pool keeps a number of threads and provides them when requested, in order to execute specific short tasks. By maintaining this pool of threads, the application increases performance and avoids latency in execution, by skipping the frequent creation and destruction of threads.

In our example, the thread pool contains three threads, all of them being busy running a specific task.

We also have a task queue, which contains the next tasks to be executed. These tasks will be fetched from the queue as soon as the threads finish with their current tasks.

In the end, the queue will be empty, the first two threads which completed their previous work have fetched the tasks from the queue, and we’re left with one thread which is ready for future work.

Reactor

Reactor is a software design pattern for event handling which handles services requests delivered concurrently, dispatching them synchronously to the associated request handlers.

In other words, the pattern is about receiving asynchronous (non-blocking) calls, and processing them synchronously (blocking) using event handlers.

With the use of this pattern, we can decouple the application-level code from the reactor implementation.

There are two main participants in the Reactor pattern:

Let’s consider a logging server. We have multiple components from multiple threads which want to log some messages to a file, for example. Therefore, we receive multiple logs at the same time, but we write them one by one.

The Reactor pattern is the synchronous variant of the Proactor pattern.

Proactor

Proactor is a software design pattern for event handling which handles services requests asynchronously. The proactor pattern can be considered to be an asynchronous variant of the synchronous reactor pattern.

In other words, the pattern is about receiving asynchronous (non-blocking) calls, and processing them asynchronously (non-blocking).

The main reason behind this pattern is to make use of performance, which is often improved by processing requests asynchronously. Therefore, long running operations are running in an asynchronous part.

At the end of the operation, a completion handler (callbacks / hooks) is called. Let’s consider a scenario in which you write a message to a friend of yours – that is the initiator, which informs your friend that you were looking for him/her.

Until they reply back, you can do whatever you want – you don’t wait for them, doing nothing (hopefully).

After they see the message, they will (again, hopefully) reply back. That makes you the completion handler, the one that processes the callback.