See example and execution result below:
#!/usr/bin/env python3.4
from multiprocessing import Pool
import time
import os
def initializer():
print(\"In initia
First off, both are meant to operate on argument-tuples (single function calls), contrary to the Pool.map
variants which operate on iterables. So it's not an error when you observe only one process used when you call these functions only once.
You would use Pool.apply_async
instead of one of the Pool.map
versions, where you need more fine grained control over the single tasks you want to distribute.
The Pool.map
versions take an iterable and chunk them into tasks, where every task has the same (mapped) target function.
Pool.apply_async
typically isn't called only once with a pool of >1 workers. Since it's asynchronous, you can iterate over manually pre-bundled tasks and submit them to several
worker-processes before any of them has completed. Your task-list here can consist of different target functions like you can see in this answer here. It also allows registering callbacks for results and errors like in this example.
These properties make Pool.apply_async
pretty versatile and a first-choice tool for unusual problem scenarios you cannot get done with one of the Pool.map
versions.
Pool.apply
indeed is not widely usefull at first sight (and second). You could use it to synchronize control flow in a scenario where you start up multiple tasks with apply_async
first and then have a task which has to be completed before you fire up another round of tasks with apply_async
.
Using Pool.apply
could also just mean sparing you to create a single extra Process for an in-between task, when you already have a pool which is currently idling.