Local Jobs UI

[andrewkaufman]

This adds a window for tracking jobs dispatched via LocalDispatchers. It adds the concept of a JobPool, and a default pool which is shared among all LocalDispatchers that use the default constructor. There is one LocalJobsWindow per JobPool, which provides a table view of the jobs in the pool, with some stats on memory and cpu usage. There is also a details tab for more information on the first selected job, and a messages tab which tracks the progress of the first selected job. Finally, there is a Kill button which can be used to interrupt the selected jobs.

The job window for the default pool can be accessed via the "Execute->View Local Jobs" menu.

Fixes #872.

Note that bb998f6 also fixed a bug where failed batches wouldn't prevent downstream requirements from executing.

[andrewkaufman]

I added a commit which fixes #1064.

[johnhaddon]

I'm getting a ps: illegal option -- s error in my shell on OS X - that argument isn't supported there, and I haven't been able to find an alternative. What's the reason for needing -s rather than just -p? Any experiments you'd like me to do at this end?

[andrewkaufman]

As far as I understood, using the session id -s ensures that all child processes will be accounted for in the stats, and using just -p will only account for that exact process, without its children. I guess maybe you could do the same by finding all the child ids manually and passing them all to -p? Do you have --sid which is the long form of -s? Does your -o option even accept sess= in the first place?

[andrewkaufman]

I guess the only real world test currently would be dispatching a RenderManRender and seeing if the cpu and mem are accounted for properly. The UI would be doing a ps on the pid that the dispatcher creates, but the node itself makes a child process inside ExecutableRender::execute.

A more general test might involve some fabricated ExecutableNode which spawns subprocesses several levels deep, and see if the total memory is accounted for or not.

[johnhaddon]

I see, that does sound desirable - SystemCommand is another that spawns a child process, so we have a few examples already. I do seem to be able to do -o sess= and get some output, but I can't find a flag to select processes by the session they're in. There's -g to select the children of a process group, but in the case of a local dispatch, everything seems to be in the process group of the Gaffer GUI, not of the gaffer execute child process. Does your session ID thing correspond directly to the gaffer execute task then?

Of course, even if we get this to work for Linux and OSX, we're still laying down a tripwire for any would-be Windows porters. There is the psutil module which seems to do all this in a cross platform way, if we can stomach another dependency. How important do you think this feature is?