[Tutor] could someone please explain multiprocessing

Alan Gauld alan.gauld at yahoo.co.uk
Sat Jul 4 07:30:20 EDT 2020


On 04/07/2020 04:01, nathan tech wrote:

> 1. There is one centralised program file, lets call this program.py.
> 
> 2. Upon launch, program.py attempts to connect to localhost:6868 (just 
> an example). If this works, it sends a message then exits.

So if it connects it send a message and exits.

> 3. If it fails, the program then listens on the said port, and waits 

But how can it listen if it failed to connect? And if it did
connect it has already exited?

> allows the user to do other things such as play other music). When it 
> receives the message it then processes it.

You started by saying program.py sent the message, but now you have
it waiting for a message? What is sending the message? How does it
know you are waiting?

> My basic aim was to try and find a way around the age old problem of:
> 
> If program is already running, don't run it again instead just tell it 
> some info.

OK, That's usually done with a launcher that just starts, checks
for an existing instance and if none found launches the real program.
If there is one, it adds the new job to a queue or sends a message
(in Unix a signal) to interrupt the existing process and restart
with a new file. (Or whatever the exact behaviour that is required.)

That means the launcher knows how to
a) locate an instance of the main program
b) lanch the mai program and
c) send a signal or message to the main program.

The main program knows how to
a) perform its primary function
b) receive messages/signals and monitor for them
c) How to extend/modify its work queue (or else pulls
   work from a known shared file)

There is no real need for threading or concurrency here.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos




More information about the Tutor mailing list