It's frustrating when you want to get something to work, and nobody's solution fits. I had already gotten quite far on a problem and had it almost done when I found this neat solution to the problem of piping error messages sent to STDERR to a file on MSDN.
I needed to either write a huge perl-script(and without a debugger that's a cramp) or reidirect the stderr and stdout from a static code analysis tool called splint so that I can gather statistics on any dodgy lines of 'C' code.
Why a beer? Well that's a celebration of a slight change in the wind. Where it will go is probably nowhere, but it's a change nonetheless.
/edit
Returning to the redirecting of standard error and pipes, the downside it the default pipe-buffer size, in fact although you can easily increase the pipe buffer size, we all know a huge buffer is in-efficient. You see, unlesss you can empty a smaller buffer in the background while the child-process is filling it, the child will get blocked if it tries to overflow the buffer. A very bad thing, normally solved by spawning a thread to process and empty things while you wait for the child to terminate. I hate and love threads, so forgoing a complex solution, I solved this by simply waiting 100ms for the child to terminate, and then emptying the stream buffer in between by polling using WaitForProcess(). It appears to solve the problem, but exactly how?.... because someone has to close the stream in order to detect the end and not get blocked yourself in the parent waiting for a read on a dead stream?
As it so happens, the parent can happily close it's copy of the redirected stream handle and then keep reading from the duplicate knowing all will unblock when the child terminates (because the handle closes in the child when it does so). Problem solved.
Tuesday, October 13, 2009
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment