Perl - doing several things at the same time
Archive - Originally posted on "The Horse's Mouth" - 2010-09-25 18:45:19 - Graham EllisWhat if you want a Perl process to go off in two different directions at the same time - perhaps a server that's going to handle several connections at the same time, or an application that's going to be doing heavy processing, but at the same time has to respond to inputs from elsewhere, such as the keyboard?
• You can have a process "fork" - divide into two processes. At the point of forking, each process will be identical except that the original ("parent") will get back the child's process number from the fork call, and the child will get a zero back; based on the one difference, the code that's run can (and usually will) diverge.
• You can start another process on a pipe - opening a file handle and reading from it or writing too it from the second process, with a buffer of 4k between the processes so that they can run asyncronously.
• You can talk to another process via a network connection - typically a TCP / IP connection. If you instigate the process, you'll typically be the "client" and you'll connect to a server that's already running - perhaps on your machine or perhaps on another system to provide a specific service.
Once you've started a second process running in one of these ways ... how do you communicate with it? On some occasions, you might not need to - you can fire off a process and leave it to its own devices as perhaps it sends an email, prints a report, runs a tidy up of the disc, and then exits. But that's not universal ...
• Before you fork, you can set up a pipe with the pipe function which (after the fork) will have connected the write file handle on the parent to the read handle on the child, and the read handle on the parent to the write handle on the child
• If you prefer (or also need) asyncronous communication between the processes, you can use a signal. A signal is a sent by the frighteningly names kill function of command, and does no more that presses a button on the receiving process to alert it to the fact that someone else needs attention. So it's then up to the receiving process, at an appropriate opportunity, to look around and do what's needed
• With network connections (TCP/IP) and also pipes to other commands, there are intrinisic read and write channels set up for communication, and it's vital that both parties to the conversation understand the protocol - otherwise you'll end up with lockups where one end is waiting for a message that never comes.
We've got all sorts of examples of these on our web site ...
[link] - forking, then the processes talk through a pipe
[link] - forking with a loop, where the parent process starts a whole school of children
[link] - two way comminucation between parent and child
[link] - A process than contacts multiple servers (tcp/ip)
[link] - simple time server
(that's just a selection - follow the links above and you'll be offered more similar examples as well!)
Threading, where you've got several things happening within the same process, is a story for another day!