Lines Matching full:processes
16 :mod:`multiprocessing` is a package that supports spawning processes using an
29 distributing the input data across processes (data parallelism). The following
31 so that child processes can successfully import that module. This basic example
61 In :mod:`multiprocessing`, processes are spawned by creating a :class:`Process`
149 Child processes no longer inherit all of the parents inheritable
156 by processes of the program. When all processes
204 processes for a different context. In particular, locks created using
205 the *fork* context cannot be passed to processes started using the
220 Exchanging objects between processes
224 processes:
266 may become corrupted if two processes (or threads) try to read from or write
268 of corruption from processes using different ends of the pipe at the same
272 Synchronization between processes
294 Without using the lock output from the different processes is liable to get all
298 Sharing state between processes
303 using multiple processes.
348 holds Python objects and allows other processes to manipulate them using
384 manager can be shared by processes on different computers over a network.
392 processes. It has methods which allows tasks to be offloaded to the worker
393 processes in a few different ways.
405 # start 4 worker processes
406 with Pool(processes=4) as pool:
423 # launching multiple evaluations asynchronously *may* use more processes
557 only. It has no semantics. Multiple processes may be given the same
580 processes.
582 Note that a daemonic process is not allowed to create child processes.
585 Unix daemons or services, they are normal processes that will be
586 terminated (and not joined) if non-daemonic processes have exited.
643 Note that descendant processes of the process will *not* be terminated --
652 cause other processes to deadlock.
715 When using multiple processes, one generally uses message passing for
716 communication between processes and avoids having to use any synchronization
720 processes) or a queue (which allows multiple producers and consumers).
758 (2) If multiple processes are enqueuing objects, it is possible for
976 Calling this has the side effect of "joining" any processes which have
1057 Return the name of start method used for starting processes.
1084 before they can create child processes.
1094 Set the method which should be used to start child processes.
1208 Connection objects themselves can now be transferred between processes
1309 :class:`multiprocessing.Lock` as it applies to either processes or threads,
1401 owned by any process or thread) and if any other processes or threads
1450 inherited by child processes.
1516 processes.
1678 processes, including sharing over a network between processes running on
1680 *shared objects*. Other processes can access the shared objects by using
1687 can be used for sharing objects between processes. The returned manager
1694 Manager processes will be shutdown as soon as they are garbage collected or
1816 of processes. Objects of this type are returned by
1820 number of commonly used data types to be synchronized across processes.
1984 Local processes can also access that queue, using the code from above on the
2038 passed between processes. As such, a referent can contain
2174 :synopsis: Create pools of processes.
2176 One can create a pool of processes which will carry out tasks submitted to it
2179 .. class:: Pool([processes[, initializer[, initargs[, maxtasksperchild [, context]]]]])
2181 A process pool object which controls a pool of worker processes to which jobs
2185 *processes* is the number of worker processes to use. If *processes* is
2194 means worker processes will live as long as the pool.
2197 the worker processes. Usually a pool is created using the
2223 Worker processes within a :class:`Pool` typically live for the complete
2328 tasks have been completed the worker processes will exit.
2332 Stops the worker processes immediately without completing outstanding
2338 Wait for the worker processes to exit. One must call :meth:`close` or
2385 with Pool(processes=4) as pool: # start 4 worker processes
2408 Usually message passing between processes is done using queues or by using
2589 wait for messages from multiple processes at once::
2665 This means that (by default) all processes of a multi-process program will share
2677 handler type) for messages from different processes to get mixed up.
2689 Note that on Windows child processes will only inherit the level of the
2734 worker threads rather than worker processes.
2737 .. class:: ThreadPool([processes[, initializer[, initargs]]])
2746 *processes* is the number of worker threads to use. If *processes* is
2757 is designed around a pool of processes and predates the introduction of
2787 between processes.
2790 between processes rather than using the lower level synchronization
2802 (There is never a problem with different processes using the *same* proxy.)
2804 Joining zombie processes
2808 :func:`~multiprocessing.active_children` is called) all completed processes
2812 practice to explicitly join all the processes that you start.
2818 processes can use them. However, one should generally avoid
2819 sending shared objects to other processes using pipes or queues.
2824 Avoid terminating processes
2830 processes.
2833 :meth:`Process.terminate <multiprocessing.Process.terminate>` on processes
2836 Joining processes that use queues
2846 process is joined. Otherwise you cannot be sure that processes which have
2848 processes will be joined automatically.
2867 Explicitly pass resources to child processes
2912 in issues with processes-in-processes. This has been changed to::
2917 Which solves the fundamental issue of processes colliding with each other
2920 with output buffering. This danger is that if multiple processes call
3023 processes and collect the results: