multiprocessing module and matplotlib.pyplot/PdfPages
davea at davea.name
Wed Apr 22 04:34:56 CEST 2015
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.
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
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
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.
More information about the Python-list