Section 5.5. Interprocess Communication
5.5. Interprocess CommunicationAs we saw earlier, when scripts spawn threadstasks that run in parallel within the programthey can naturally communicate by changing and inspecting shared global memory. As we also saw, some care must be taken to use locks to synchronize access to shared objects that can't be updated concurrently, but it's a fairly straightforward communication model. Things aren't quite as simple when scripts start processes and programs. If we limit the kinds of communications that can happen between programs, many options are available, most of which we've already seen in this and the prior chapters. For example, the following can all be interpreted as cross-program communication devices:
For instance, sending command-line options and writing to input streams lets us pass in program execution parameters; reading program output streams and exit codes gives us a way to grab a result. Because shell variable settings are inherited by spawned programs, they provide another way to pass context in. Pipes made by os.popen and simple files allow even more dynamic communication. Data can be sent between programs at arbitrary times, not only at program start and exit. Beyond this set, there are other tools in the Python library for performing Inter-Process Communication (IPC). Some vary in portability, and all vary in complexity. For instance, in the Internet scripting part of this text we will meet the Python socket module, which lets us transfer data between programs running on the same computer as well as programs located on remote networked machines. In this section, we introduce pipesboth anonymous and namedas well as signals, or cross-program event triggers. Other IPC tools are available to Python programmers (e.g., shared memory; see the mmap module) but are not covered here for lack of space; search the Python manuals and web site for more details on other IPC schemes if you're looking for something more specific. |
