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...@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
--
https://mail.python.org/mailman/listinfo/python-list
