{"id":1947,"date":"2009-11-12T00:21:05","date_gmt":"2009-11-12T07:21:05","guid":{"rendered":"http:\/\/multimedia.cx\/eggs\/?p=1947"},"modified":"2020-07-25T22:48:45","modified_gmt":"2020-07-26T05:48:45","slug":"process-of-confusion","status":"publish","type":"post","link":"https:\/\/multimedia.cx\/eggs\/process-of-confusion\/","title":{"rendered":"Process of Confusion"},"content":{"rendered":"

I am working hard at designing a better FATE<\/a> right now. But first thing’s first: I’m revisiting an old problem and hoping to conclusively determine certain process-related behavior.<\/p>\n

I first described the problem in this post<\/a> and claimed in this post that I had hacked around the problem.<\/a> Here’s the thing: When I spin off a new process to run an FFmpeg command line, Python’s process object specifies a PID. Who does this PID belong to? The natural assumption would be that it belongs to FFmpeg. However, I learned empirically that it actually belongs to a shell interpreter that is launching the FFmpeg command line, which has a PID 1 greater than the shell interpreter. So my quick and dirty solution was to assume that the actual FFmpeg PID was 1 greater than the PID returned from Python’s subprocess.Popen() call.<\/p>\n

Bad assumption.<\/em> The above holds true for Linux but not for Mac OS X, where the FFmpeg command line has the returned PID. I’m not sure what Windows does.<\/p>\n

This all matters for the timeout killer. FATE guards against the possibility of infinite loops by specifying a timeout for each test. Timeouts don’t do much good when they trigger TERM and KILL signals to the wrong PID. I tested my process runner carefully when first writing FATE (on Linux) and everything worked okay with using the same PID returned by the API. I think that was because I was testing the process runner using the built-in ‘sleep’ shell command. This time, I wrote a separate program called ‘hangaround’ that takes a number of seconds to hang around before exiting. This is my testing methodology:<\/p>\n