[Tutor] could someone please explain multiprocessing

[nathan tech]

Hi Alan,

Thanks for your response, as always you somehow manage to decode my 
ramblings into order, then state the solution in an obvious way that 
makes me smack my forever and go, "duh!"


I admit part of me had been half avoiding shared files because in my 
head I'm thinking, it's going to have to keep checking that file on a 
regular basis which is a lot of open, close, open, close.

With the signal solution though it would only do it when signaled to do 
so. Genius!


Just to make sure I have this right, would you mind glancing over this 
Seudo code?


      Launcher:

import psutil

  currently_running=[]

  for process in running_processes:

   if(process["name"]=="my_programs_launcher" or 
process["name"]=="my_programs_name"):

    running.append(process["id"])

  if(len(running)==1):

   # we are the only one! Launch the main program and job done.

  else:

   # we are already running. Open the shared file, append the arguments, 
and then send a signal


   Main program:

  # do all the things

  # check to see if any signals have been received

  if(signal_received):

   # open the file and process it, deleting and or clearing the file 
after so that it does not repeat itself. Could a method here be 
something like:

  if(file_last_modified(path)>last_time_this_program_accessed_it):

    # process contents and update variables


Thanks for your help as always.

Nathan

On 04/07/2020 12:30, Alan Gauld via Tutor wrote:
> 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.
>