multiprocessing module and matplotlib.pyplot/PdfPages

[Dave Angel]

On 04/21/2015 07:54 PM, Dennis Lee Bieber wrote:
> On Tue, 21 Apr 2015 18:12:53 +0100, Paulo da Silva
> <p_s_d_a_s_i_l_v_a_ns at netcabo.pt> declaimed the following:
>
>
>>
>> Yes. fork will do that. I have just looked at it and it is the same as
>> unix fork (module os). I am thinking of launching several forks that
>> will produce .png images and at the end I'll call "convert" program to
>> place those .png files into a pdf book. A poor solution but much faster.
>>
>
> 	To the best of my knowledge, on a UNIX-type OS, multiprocessing /uses/
> fork() already. Windows does not have the equivalent of fork(), so
> multiprocessing uses a different method to create the process
> (conceptually, it runs a program that does an import of the module followed
> by a call to the named method -- which is why one must follow the
>
> if __name__  ...
>
> bit prevent the subprocess import from repeating the original main program.
>

The page:
 
https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods

indicates that there are 3 ways in which a new process may be started. 
On Unix you may use any of the three, while on Windows, you're stuck 
with spawn.

I *think* that in Unix, it always does a fork.  But if you specify 
"spawn" in Unix, you get all the extra overhead to wind up with what 
you're describing above.  If you know your code will run only on Unix, 
you presumably can get much more efficiency by using the fork 
start-method explicitly.

I haven't done it, but it would seem likely to me that forked code can 
continue to use existing global variables.  Changes to those variables 
would not be shared across the two forked processes.  But if this is 
true, it would seem to be much easier way to launch the second process, 
if it's going to be nearly identical to the first.

Maybe this is just describing the os.fork() function.
    https://docs.python.org/3.4/library/os.html#os.fork

-- 
DaveA