Re: More spawn & Windows processes

[Christopher Faylor <me at cgf dot cx>]

On Mon, Dec 27, 2004 at 12:56:55PM -0500, Pierre A. Humblet wrote:
>At 11:18 AM 12/27/2004 -0500, Christopher Faylor wrote:
>>On Mon, Dec 27, 2004 at 11:07:49AM -0500, Pierre A. Humblet wrote:
>>>At 11:05 AM 12/27/2004 -0500, Christopher Faylor wrote:
>>>>On Mon, Dec 27, 2004 at 10:51:58AM -0500, Pierre A. Humblet wrote:
>>>>>  should now be able to save microseconds by simply closing the pipe.
>>>>
>>>>Did you happen to notice that it *used* to be a CloseHandle?
>>>
>>>Yes. I think you changed it in an attempt to make P_DETACH work.
>>
>>No.  I remember that you floated that theory but it really had nothing
>>to do with that.  I wanted to guarantee that the parent process saw a
>>"close" regardless of whether there were other processes with the pipe
>>open.  It's a paranoia thing as I round onto releasing 1.5.13.
>
>OK. At the time you made it, the change was in fact necessary because
>there could be another process with the pipe open (a detached process).

No, it wasn't necessary because a detached process didn't get the pipe.

2004-12-23  Christopher Faylor  <cgf@timesys.com>

        * pinfo.cc (_pinfo::exit): Signal exit more forcibly.
        * sigproc.cc (proc_subproc): Add support for PROC_DETACHED_CHILD.

Although the two things were checked in at the same time, they were
unrelated.  I was working on a problem that Corinna had reported in
private email.

>The mindboggling line is 
>  _pinfo::dup_proc_pipe: closed wr_proc_pipe 0x4 for pid 1014051(4293972685)
>It indicates that it's apparently possible to successfully duplicate a pipe into
>a process that has exited! That open pipe is keeping the original sh waiting for
>the "termination" of its child. 

!!!!!!!!!!!!!!!!!!

You know, I was wondering if that was going to be a problem when I wrote that
code and I thought that it couldn't possibly be a problem.  No OS could be so
brain dead as to allow what you've apparently discovered.

I was just looking into this, too, and the strace didn't make much sense.  Now,
I guess I see why.

I'll add a workaround.  I do so love to slow down code for the sake of the Win9x
family.

cgf