As we saw earlier, when scripts spawn
threads—tasks that run in parallel within the
program—they can naturally communicate by changing and inspecting
names and objects in shared global memory. This includes both
accessible variables and attributes, as well as referenced mutable
objects. As we also saw, some care must be taken to use locks to
synchronize access to shared items that can be updated concurrently.
Still, threads offer a fairly straightforward communication model, and
queue module can make this
nearly automatic for many programs.
Things aren’t quite as simple when scripts start child processes and independent programs that do not share memory in general. 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 simple mechanisms can all be interpreted as cross-program communication devices:
Program exit status codes
Shell environment variables
Standard stream redirections
Stream pipes managed by
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 environment variable settings are inherited by spawned programs,
they provide another way to pass context in. And pipes made by
subprocess allow ...