There are many different ways to communicate among processes. Pipe, socket, ..., SOAP. Each has its advantages and disadvantages, but on unix, using pipe probably requires the least amount of development effort. However, pipe is not quite portable.

Some interesting points about pipe:

• Pipe is the abstraction of a type of unidirectional stream communication. It involves two user processes, one write-end and one read-end. The stream going through pipe is unstructured, as far as the pipe sees. Whether the data you send is structured, is really your design consideration, which your program cares and understands, but not the pipe.
• The internal implementation of a pipe, is actually a buffer + two descriptors + two pointers. The writer pointer advances, when the writer process writes to the buffer, and the reader pointer advances, when the reader process reads from the buffer.
• When your process writes to/reads from a descriptor, it does not really care whether the descriptor is a process or a file, or whatever. It is just another descriptor.

Another thing I want to mention is that, traditionally, Perl deal with lots of forked processes, but I personally believe that, as Perl's threading support becomes more and more stable and powerful, in the future, we should expect less forks (I am saying lots of things required fork in the past, will be done by using threading in the future. However as long as process is there, inter-process communication will remain there. There are lots of articles talking about why process, why threading. My view is that really depends on the application, configuration, environment, situation etc.)