Reap child processes

[FJShen]

This screenshot of the tree-view of running processes was taken when the trace post processor has finished processing 2 kernels and was in the midst of processing the third.

For the first two kernels, the child process forked for supplying raw traces to the post processor, and the child process forked for consuming the post-processed trace were never "reaped" after they have completed. As a result, their corresponding processes remain in a zombie state and won't really "disappear" until the parent process has terminated. The overhead of this wacky behavior is small, but each zombie process occupies an entry in the process table. In the case a post-processor needs to process many kernels, the process table could end up filling up.

The remedy to this problem is to call wait() or waitpid() in the parent process.

This remedy should be applied to the trace post processor program. However, despite the tracer program and the PipeReader object of the simulator program also uses xz subprocesses, they are not affected, because they do not explicitly use fork to spawn the children processes.

[JRPan]

I think the reason for multi-processing is for using one process for cin? I'm updating it to use fopen and pip just like the simulator frontend. So this should be fixed with that?

Also it might not be a bad idea to multi-process trace post-processing, if the memory consumption can be reduced significantly with binary traces in #471

[FJShen]

I agree with both points.

To elaborate on the first point, the original code stuck with std::cin so that the code change wouldn't look too foreign to a code reviewer, but now that it's in the mainline branch, switching to popen/fopen would make the code cleaner.