gonzalo-bulnes/inter_process_communication_demo

Playing with named pipes in Ruby.

Demo: Inter-process Communication

An example Ruby program to be used as a proof of concept for inter-process commnication between a main program which needs to delegate hooks processing and a worker program which performs those hooks.

Idea

The first example uses named pipes to allow the main program to delegate one hook to the worker.

The second example was an attempt to use signals to allow the worker to peform multiple hooks depending on the main program needs. The attempt failed.

The third example succeeds at performing an arbitrary number of hooks by forking the worker, thus allowing it to read from a named pipe as long as the main program is running.

Usage

Note: for now, there are no signals involved.

Install dependencies, using RVM is optional but strongly recommended:

# trigger the RVM hooks so the gems get installed in an dedicated gemset
cd inter_process_communication_demo

# install dependencies
bundle install

Basic named pipes

Create the named pipes that will be used by main.rb and worker.rb to communicate:

cd lib/01_basic_named_pipes

# create a named pipe for the main program to notify
# the worker about a hook to be performed
mkfifo main_to_worker

# create another named pipe for the worker to reply
# to the main program
mkfifo worker_to_main

# once you're done using them, remove both pipes:
#rm main_to_worker worker_to_main

In the fist scenario, the worker is waiting for hook requests:

# Scenario 1

# start the worker
ruby worker.rb # will wait until there is a hook to perform

# in a distinct terminal, start the main program
ruby main.rb # since the worker is available, the hook is performed immediately

In the second scenario, the main program is waiting for workers to be available:

# Scenario 2

# start the main program
ruby main.rb # will wait until a wroker preforms the hook

# in a distinct terminal, start the worker
ruby worker.rb # since a hook request was performed, performs the hook immediately

Signals

Note: Signals don't seem to be the way to go, see these signals limitations.

The idea was having a worker_on_demand, which would start the main program (provinding its own PID to it). The main program would sent a signal each time a hook would need to be performed.

cd lib/02_signals

# start
ruby worker_on_demand.rb # multiple hook requests are handled by the worker

Named pipes and fork

The first example has two limitations:

• only one hook request can be handled by the worker
• the main program and the worker must agree on two named pipes to communicate

To be able to handle any number of hook requests, the worker must be able to loop while the main program is running. Of course, it should exit once the main program has exited.

In order to do so, let's introduce the worker_provider program. It will start a looping worker, then start the main program, and make sure the worker exits when the main program does. It will also provide both named pipes to both the worker and the main program.

cd lib/03_named_pipes_and_fork

# start the worker provider program
ruby worker_provider.rb # will start a worker and a main program with several hooks to perform

References

• Using Named Pipes in Ruby for Inter-process Communication
• Ruby 2.2.0 documentation: Process
• Forking and IPC in Ruby, Part II