On Sun, Nov 14, 2004 at 12:34:30PM -0500, Pierre A. Humblet wrote: >At 12:11 AM 11/14/2004 -0500, Christopher Faylor wrote: >> >>When you first mentioned this, I had an idea that maybe we could be >>waiting on something else besides a process handle which would be >>inherited by any subprocesses. I thought that maybe we could somehow >>use a mutex but there would always be a period when you'd have to do >>some tricky synchronization to make sure that the child gets to lock the >>mutex but the parent doesn't. >> >>I don't know how many times I have wished for a non-process handle that >>would become signalled when a process exits. >> >>So, today, it occurred to me that pipes could come to the rescue again. >>If we opened a pipe and put the write end in every child process, the >>parent could wait on the read end of the pipe. When the last child >>process dies, the parent would wake up and do what it does now. >> >>At first, I was hoping that pipes would work correctly when called >>with WaitFor* and we could just drop pipe handles in there. Of course, >>it can't be that simple and I really should have known that wouldn't >>work. I think I have tried this technique about twice a year since >>1998. >> >>Instead, you have to use ReadFile in a thread. So, the children would >>gain an extra open handle, the parent would get some new threads. But >>the parent would be able to track A LOT more subprocesses than the >>current 63. > >That would be the key advantage of this approach. Do you have a >way (async I/O?) to avoid having one thread per child?
AFAIK, you can't do async I/O on anonymous pipes. >BTW, have you ever tried using select, having a connection from the >parent to the child? select involves polling or setting up other events to track end-of-pipe conditions. I don't think that's a win. >>When I get the code to a point that it can run configure, I'll do a >>benchmark and see how bad this technique is. If there is not a >>noticeable degradation, I think I'll probably duplicate the scenario of >>last year and checkin this revamp which, I believe will eliminate the >>security problem that you were talking about. > >There is also the case where a setuid child needs to signal its parent. >That's another use of my ppid_waitsig, avoiding the PROCESS_DUP_HANDLE >issue. >Could your "end of pid" pipe be used to transmit signals, with the reader >thread forwarding the sigpacket to the local sigthread? It could but that's not its intent. It's used now to transmit stop/continue state but if you need to send a signal from parent to child, I don't think it makes sense to relay it through this mechanism. cgf