From: Pierre Glaser Date: Mon, 13 May 2019 17:20:48 +0000 (+0200) Subject: bpo-36867: DOC update multiprocessing.rst (GH-13289) X-Git-Tag: v3.8.0b1~384 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=50466c66509de556a8579172f82d1abb1560d8e4;p=python bpo-36867: DOC update multiprocessing.rst (GH-13289) Followup to bpo-36867. --- diff --git a/Doc/library/multiprocessing.rst b/Doc/library/multiprocessing.rst index a5ecfa6cc1..c6ffb00819 100644 --- a/Doc/library/multiprocessing.rst +++ b/Doc/library/multiprocessing.rst @@ -131,13 +131,17 @@ to start a process. These *start methods* are handles on Windows. On Unix using the *spawn* or *forkserver* start methods will also -start a *semaphore tracker* process which tracks the unlinked named -semaphores created by processes of the program. When all processes -have exited the semaphore tracker unlinks any remaining semaphores. +start a *resource tracker* process which tracks the unlinked named +system resources (such as named semaphores or +:class:`~multiprocessing.shared_memory.SharedMemory` objects) created +by processes of the program. When all processes +have exited the resource tracker unlinks any remaining tracked object. Usually there should be none, but if a process was killed by a signal -there may be some "leaked" semaphores. (Unlinking the named semaphores -is a serious matter since the system allows only a limited number, and -they will not be automatically unlinked until the next reboot.) +there may be some "leaked" resources. (Neither leaked semaphores nor shared +memory segments will be automatically unlinked until the next reboot. This is +problematic for both objects because the system allows only a limited number of +named semaphores, and shared memory segments occupy some space in the main +memory.) To select a start method you use the :func:`set_start_method` in the ``if __name__ == '__main__'`` clause of the main module. For