Unix daemons or services, they are normal processes that will be
terminated (and not joined) if non-daemonic processes have exited.
- In addition to the :class:`Threading.Thread` API, :class:`Process` objects
+ In addition to the :class:`threading.Thread` API, :class:`Process` objects
also support the following attributes and methods:
.. attribute:: pid
The process's authentication key (a byte string).
When :mod:`multiprocessing` is initialized the main process is assigned a
- random string using :func:`os.random`.
+ random string using :func:`os.urandom`.
When a :class:`Process` object is created, it will inherit the
authentication key of its parent process, although this may be changed by
.. warning::
As mentioned above, if a child process has put items on a queue (and it has
- not used :meth:`JoinableQueue.cancel_join_thread`), then that process will
+ not used :meth:`JoinableQueue.cancel_join_thread
+ <multiprocessing.Queue.cancel_join_thread>`), then that process will
not terminate until all buffered items have been flushed to the pipe.
This means that if you try joining that process you may get a deadlock unless
call to :meth:`task_done` tells the queue that the processing on the task
is complete.
- If a :meth:`~Queue.join` is currently blocking, it will resume when all
+ If a :meth:`~Queue.Queue.join` is currently blocking, it will resume when all
items have been processed (meaning that a :meth:`task_done` call was
received for every item that had been :meth:`~Queue.put` into the queue).
queue. The count goes down whenever a consumer thread calls
:meth:`task_done` to indicate that the item was retrieved and all work on
it is complete. When the count of unfinished tasks drops to zero,
- :meth:`~Queue.join` unblocks.
+ :meth:`~Queue.Queue.join` unblocks.
Miscellaneous
array.
If *lock* is ``True`` (the default) then a new lock object is created to
- synchronize access to the value. If *lock* is a :class:`Lock` or
- :class:`RLock` object then that will be used to synchronize access to the
+ synchronize access to the value. If *lock* is a
+ :class:`~multiprocessing.Lock` or :class:`~multiprocessing.RLock` object
+ then that will be used to synchronize access to the
value. If *lock* is ``False`` then access to the returned object will not be
automatically protected by a lock, so it will not necessarily be
"process-safe".
object.
If *lock* is ``True`` (the default) then a new lock object is created to
- synchronize access to the value. If *lock* is a :class:`Lock` or
- :class:`RLock` object then that will be used to synchronize access to the
+ synchronize access to the value. If *lock* is a :class:`~multiprocessing.Lock` or
+ :class:`~multiprocessing.RLock` object then that will be used to synchronize access to the
value. If *lock* is ``False`` then access to the returned object will not be
automatically protected by a lock, so it will not necessarily be
"process-safe".
:attr:`proxytype._exposed_` is used instead if it exists.) In the case
where no exposed list is specified, all "public methods" of the shared
object will be accessible. (Here a "public method" means any attribute
- which has a :meth:`__call__` method and whose name does not begin with
- ``'_'``.)
+ which has a :meth:`~object.__call__` method and whose name does not begin
+ with ``'_'``.)
*method_to_typeid* is a mapping used to specify the return type of those
exposed methods which should return a proxy. It maps method names to
:synopsis: API for dealing with sockets.
Usually message passing between processes is done using queues or by using
-:class:`Connection` objects returned by :func:`Pipe`.
+:class:`~multiprocessing.Connection` objects returned by
+:func:`~multiprocessing.Pipe`.
However, the :mod:`multiprocessing.connection` module allows some extra
flexibility. It basically gives a high level message oriented API for dealing
private temporary directory created using :func:`tempfile.mkstemp`.
If the listener object uses a socket then *backlog* (1 by default) is passed
- to the :meth:`listen` method of the socket once it has been bound.
+ to the :meth:`~socket.socket.listen` method of the socket once it has been
+ bound.
If *authenticate* is ``True`` (``False`` by default) or *authkey* is not
``None`` then digest authentication is used.
.. method:: accept()
Accept a connection on the bound socket or named pipe of the listener
- object and return a :class:`Connection` object. If authentication is
- attempted and fails, then :exc:`AuthenticationError` is raised.
+ object and return a :class:`~multiprocessing.Connection` object. If
+ authentication is attempted and fails, then
+ :exc:`~multiprocessing.AuthenticationError` is raised.
.. method:: close()
Authentication keys
~~~~~~~~~~~~~~~~~~~
-When one uses :meth:`Connection.recv`, the data received is automatically
+When one uses :meth:`Connection.recv <multiprocessing.Connection.recv>`, the
+data received is automatically
unpickled. Unfortunately unpickling data from an untrusted source is a security
risk. Therefore :class:`Listener` and :func:`Client` use the :mod:`hmac` module
to provide digest authentication.
On Unix when a process finishes but has not been joined it becomes a zombie.
There should never be very many because each time a new process starts (or
- :func:`active_children` is called) all completed processes which have not
- yet been joined will be joined. Also calling a finished process's
- :meth:`Process.is_alive` will join the process. Even so it is probably good
+ :func:`~multiprocessing.active_children` is called) all completed processes
+ which have not yet been joined will be joined. Also calling a finished
+ process's :meth:`Process.is_alive <multiprocessing.Process.is_alive>` will
+ join the process. Even so it is probably good
practice to explicitly join all the processes that you start.
Better to inherit than pickle/unpickle
Avoid terminating processes
- Using the :meth:`Process.terminate` method to stop a process is liable to
+ Using the :meth:`Process.terminate <multiprocessing.Process.terminate>`
+ method to stop a process is liable to
cause any shared resources (such as locks, semaphores, pipes and queues)
currently being used by the process to become broken or unavailable to other
processes.
Therefore it is probably best to only consider using
- :meth:`Process.terminate` on processes which never use any shared resources.
+ :meth:`Process.terminate <multiprocessing.Process.terminate>` on processes
+ which never use any shared resources.
Joining processes that use queues
resulting in a bad file descriptor error, but introduces a potential danger
to applications which replace :func:`sys.stdin` with a "file-like object"
with output buffering. This danger is that if multiple processes call
- :func:`close()` on this file-like object, it could result in the same
+ :meth:`~io.IOBase.close()` on this file-like object, it could result in the same
data being flushed to the object multiple times, resulting in corruption.
If you write a file-like object and implement your own caching, you can
as the ``target`` argument on Windows --- just define a function and use
that instead.
- Also, if you subclass :class:`Process` then make sure that instances will be
- picklable when the :meth:`Process.start` method is called.
+ Also, if you subclass :class:`~multiprocessing.Process` then make sure that
+ instances will be picklable when the :meth:`Process.start
+ <multiprocessing.Process.start>` method is called.
Global variables
Bear in mind that if code run in a child process tries to access a global
variable, then the value it sees (if any) may not be the same as the value
- in the parent process at the time that :meth:`Process.start` was called.
+ in the parent process at the time that :meth:`Process.start
+ <multiprocessing.Process.start>` was called.
However, global variables which are just module level constants cause no
problems.
.. literalinclude:: ../includes/mp_newtype.py
-Using :class:`Pool`:
+Using :class:`~multiprocessing.pool.Pool`:
.. literalinclude:: ../includes/mp_pool.py
This is a straightforward interface to the Unix :c:func:`select` system call.
The first three arguments are sequences of 'waitable objects': either
integers representing file descriptors or objects with a parameterless method
- named :meth:`fileno` returning such an integer:
+ named :meth:`~io.IOBase.fileno` returning such an integer:
* *rlist*: wait until ready for reading
* *wlist*: wait until ready for writing
Among the acceptable object types in the sequences are Python file objects (e.g.
``sys.stdin``, or objects returned by :func:`open` or :func:`os.popen`), socket
objects returned by :func:`socket.socket`. You may also define a :dfn:`wrapper`
- class yourself, as long as it has an appropriate :meth:`fileno` method (that
- really returns a file descriptor, not just a random integer).
+ class yourself, as long as it has an appropriate :meth:`~io.IOBase.fileno`
+ method (that really returns a file descriptor, not just a random integer).
.. note::
.. method:: poll.register(fd[, eventmask])
Register a file descriptor with the polling object. Future calls to the
- :meth:`poll` method will then check whether the file descriptor has any pending
- I/O events. *fd* can be either an integer, or an object with a :meth:`fileno`
- method that returns an integer. File objects implement :meth:`fileno`, so they
- can also be used as the argument.
+ :meth:`poll` method will then check whether the file descriptor has any
+ pending I/O events. *fd* can be either an integer, or an object with a
+ :meth:`~io.IOBase.fileno` method that returns an integer. File objects
+ implement :meth:`!fileno`, so they can also be used as the argument.
*eventmask* is an optional bitmask describing the type of events you want to
check for, and can be a combination of the constants :const:`POLLIN`,
Remove a file descriptor being tracked by a polling object. Just like the
:meth:`register` method, *fd* can be an integer or an object with a
- :meth:`fileno` method that returns an integer.
+ :meth:`~io.IOBase.fileno` method that returns an integer.
Attempting to remove a file descriptor that was never registered causes a
:exc:`KeyError` exception to be raised.
Run command with arguments. Wait for command to complete. If the return
code was zero then return, otherwise raise :exc:`CalledProcessError`. The
:exc:`CalledProcessError` object will have the return code in the
- :attr:`returncode` attribute.
+ :attr:`~CalledProcessError.returncode` attribute.
The arguments shown above are merely the most common ones, described below
in :ref:`frequently-used-arguments` (hence the slightly odd notation in
If the return code was non-zero it raises a :exc:`CalledProcessError`. The
:exc:`CalledProcessError` object will have the return code in the
- :attr:`returncode` attribute and any output in the :attr:`output`
- attribute.
+ :attr:`~CalledProcessError.returncode` attribute and any output in the
+ :attr:`~CalledProcessError.output` attribute.
The arguments shown above are merely the most common ones, described below
in :ref:`frequently-used-arguments` (hence the slightly odd notation in
.. method:: Popen.poll()
- Check if child process has terminated. Set and return :attr:`returncode`
- attribute.
+ Check if child process has terminated. Set and return
+ :attr:`~Popen.returncode` attribute.
.. method:: Popen.wait()
- Wait for child process to terminate. Set and return :attr:`returncode`
- attribute.
+ Wait for child process to terminate. Set and return
+ :attr:`~Popen.returncode` attribute.
.. warning::
In addition, the replacements using :func:`check_output` will fail with a
:exc:`CalledProcessError` if the requested operation produces a non-zero
- return code. The output is still available as the ``output`` attribute of
- the raised exception.
+ return code. The output is still available as the
+ :attr:`~CalledProcessError.output` attribute of the raised exception.
In the following examples, we assume that the relevant functions have already
been imported from the :mod:`subprocess` module.
projects / python / commitdiff