resolving piped logging bugs...

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Just a quick update; I have windows running again after creating a NUL
(/dev/null) association for the parent processes' stdout handle.  It solves
a regression introduced in r483967 on Windows.

I'm somewhat puzzled, on traditional unix, NO_PIPE values for stdin/out/err
would pass no fd at all, AIUI.  It seems (?) that we presume they clone the
parent's respective handles, if spelled out explicitly?

We have a ton of leaking pipes and I'm trying to hunt them all down.  Found
the big one, we never set our own stderr handle as non-inherited before
spawning the replacement stderr handler process, so it was *still* holding
the old piped error logger open (just, not as stderr 'proper', but a plain
old file handle).

Still problems to hunt down, this is 40 hours into it.  But I should have
the simplest possible patches ready sometime tomorrow for folks to comment
on and review.

Bill

Re: resolving piped logging bugs...

[Jeff Trawick <tr...@gmail.com>]

On 8/20/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Just a quick update; I have windows running again after creating a NUL
> (/dev/null) association for the parent processes' stdout handle.  It solves
> a regression introduced in r483967 on Windows.

D00d!!!!!!!!!!!!!!!!!!!!!!