The article you found is in the right direction but may be more than you need.
When you spawn a new process (in Python or any other language for that matter) you are basically "cloning" the parent process and then proceeding to do new things in the child process. The parent process still exists and needs to monitor the child processes so that you don't get the dreaded "zombie" processes once a child process exits.
Basically, you need some form of inter-process communication (IPC)* The simplest form of IPC that could be good enough for your purposes is to look at "signals". The signal is a very simple numeric return code that you get when your child process exits. You can wait on a child process and listen for the signal to indicate that the encoding program has exited. The numeric return value can sometimes tell you if the program succeeded or failed too. Generally speaking, a signal return of "0" means success, and other numbers indicate some sort of error or that the program was aborted.
It looks like you are spawning a bunch of processes to do FLAAC --> AAC conversions in this program. I would recommend a "fire and forget" approach where each child process only ever runs a single encoding program on a single file. The parent program (Manager) is simply responsible for controlling how many children are spawned at once. When once child program exits, you get a return code and the parent program spawns another child to handle the next file. You don't need to do complicated IPC this way, just fire off a new child process after an earlier child process gets finished. Since you have multiple child processes, I would recommend using Python's asynchronous waiting functions like the "poll" function from the subprocess module (see a more in-depth explanation here: http://stackoverflow.com/questions/6365 ... rom-python
) The advantage to using asynchronous calls is that they are non-blocking, meaning you can check the status of a child process without forcing the parent to wait until the child is closed. You can use a monitoring loop and go down the full list of child processes every so often to see which ones are running and which ones have exited, and spawn new child processes accordingly.
* Without using some form of IPC you can't have two processes talk to each other. Using a trivial example, say we have a parent process with a variable A = 10. Next, we spawn a child process that gets its own copy of the variable, A = 10. Now say the parent changes A: A += 1. The child process still sees A = 10
because the child is now a completely different process, even if both the parent and child have the same "A" variable. This is a difference between multi-process and multi-threaded programming, because in a multi-threaded program if "A" has the correct visibility, then both a parent thread and child thread see a single value of "A" in a single memory space. Multi-process programming (like what you are doing) means that the child has its own memory space that is completely separate from the parent process, just like the memory space that the OS is showing to my web browser is kept separate from the one it is showing to my command terminal. You can read up more in "virtual memory" in modern operating systems for how this works.
Yes your system is faster than mine. But mine is old enough to operate as a time machine so that I can be a roadie for Hüsker Dü. So therefore mine is *AWESOMER*.
Oh, and GET OFF MY LAWN.