[Tutor] Multiprocessing

[Stephen M Smith]

Thanks - I don't get all of the subtleties of python yet. I am picking it up
after a long career in much older technology. I don't think in python yet -
may never. In any event I understand what has happened and the change to
make, don't really understand the why.

Thanks so much for your help...This is a great forum and I see you are quite
active on it.

Stay safe and healthy.

-----Original Message-----
From: Cameron Simpson <cs at cskk.id.au> 
Sent: Tuesday, September 22, 2020 6:18 AM
To: Stephen M Smith <stephen.m.smith at comcast.net>
Cc: tutor at python.org
Subject: Re: [Tutor] Multiprocessing

On 22Sep2020 05:56, Stephen M Smith <stephen.m.smith at comcast.net> wrote:
>I added your suggested line of code (in first test after the print 
>statement and then both before and after)  and get the same result. I 
>also shut my system down and restarted it and pycharm to make sure 
>everything was as clean as possible.Thanks.

I've done somw more reading. Are you on Windows (guessing so from the
"Outlook" mailer header and the double spacing of the pasted text)?

On Windows the default subprocess mechanism is "spawn". This spawns a new
Python interpreter and imports your module again. The implication of this is
that the module source code is rerun in the child process.

So, what's going on there?

All the unconditional code in your module is run in each child process.  
So your leading print() call is run again every time.

However, the child processes are not running your module as the "main
programme" (detected by __name__ == '__main__'). So in the child process,
the code _inside_ the "if __name__ == '__main__'" is _not_ run.

So the design rule here is: do nothing with side effects before the
"if-main" part. Define the do_something function (because you need that; it
is what you're asking to be run), but don't do any print()s - the produce
output (a side effect).

Does this clarify things?

Cheers,
Cameron Simpson <cs at cskk.id.au>