[Python编程(第4版)].(Programming.Python.4th.Edition).Mark.Lutz.文字版

(yzsuai) #1

This precludes a common coding pattern that uses lambda to add data to calls, which
we’ll use often for callbacks in the GUI part of this book. Moreover, this differs from
the threading module that is the model for this package—calls like the following which
work for threads must be translated to a callable and arguments:


threading.Thread(target=(lambda: action(2, 4))).start() # but lambdas work here

Conversely, some behavior of the threading module is mimicked by multiprocessing,
whether you wish it did or not. Because programs using this package wait for child
processes to end by default, we must mark processes as daemon if we don’t want to block
the shell where the following sort of code is run (technically, parents attempt to ter-
minate daemonic children on exit, which means that the program can exit when only
daemonic children remain, much like threading):


def action(arg1, arg2):
print(arg1, arg2)
time.sleep(5) # normally prevents the parent from exiting

if __name__ == '__main__':
p = Process(target=action, args=('spam', 'eggs'))
p.daemon = True # don't wait for it
p.start()

There’s more on some of these issues in the Python library manual; they are not show-
stoppers by any stretch, but special cases and potential pitfalls to some. We’ll revisit
the lambda and daemon issues in a more realistic context in Chapter 8, where we’ll use
multiprocessing to launch GUI demos independently.


Why multiprocessing? The Conclusion


As this section’s examples suggest, multiprocessing provides a powerful alternative
which aims to combine the portability and much of the utility of threads with the fully
parallel potential of processes and offers additional solutions to IPC, exit status, and
other parallel processing goals.


Hopefully, this section has also given you a better understanding of this module’s
tradeoffs discussed at its beginning. In particular, its separate process model precludes
the freely shared mutable state of threads, and bound methods and lambdas are pro-
hibited by both the pickleability requirements of its IPC pipes and queues, as well as
its process action implementation on Windows. Moreover, its requirement of pickle-
ability for process arguments on Windows also precludes it as an option for conversing
with clients in socket servers portably.


While not a replacement for threading in all applications, though, multiprocessing
offers compelling solutions for many. Especially for parallel-programming tasks which
can be designed to avoid its limitations, this module can offer both performance and
portability that Python’s more direct multitasking tools cannot.


The multiprocessing Module| 257
Free download pdf