[PATCH]: broken pipe

[Christopher Faylor]

On Mon, Aug 30, 2004 at 07:24:40PM -0400, Pierre A. Humblet wrote:
>At 12:22 AM 8/30/2004 -0400, Christopher Faylor wrote:
>>On Sun, Aug 29, 2004 at 12:51:54PM -0400, Pierre A. Humblet wrote:
>>
>>>
>>>My solution is for the parent fork to return the cygpid calculated
>>>from the winpid.
>>>The test program is still running after 100,000 fork/exec/pipe,
>>>a longevity record. 
>>
>>Wouldn't the below solve this problem more minimally?  It moves the
>>setting of forked_pid to after it is known that the pinfo structure
>>has been filled out.
>
>That will work just fine as well.
>
>Having spent time understanding the program flow, I thought it would
>help others to see unambiguously that the forked cygpid is the already
>known winpid (on NT).  Waiting to read the pinfo suggests that the
>child may have put something different in there.

Which is what I wanted to achieve, actually.  I wanted to make it clear
that the setting of the pid was under the child's control.  If you
assume that the pid is always going to be X in two places then, at some
point in the future, when you change the pid to be Y you have to
remember to change two places.

>>>Two other comments:
>>>- there is still a race to create the pinfo. Hopefully all versions
>>>of Windows handle it properly. To be on the safe side, the parent could
>>>open (not create) the pinfo after the child's longjmp.
>>>- the parent copies myself->progname into the child. This seems
>>>duplicative, given that the child always sets progname from 
>>>GetModuleFileName in set_myself.
>>
>>I'm not clear on why you think the race is a problem.  The end result
>>should be that the correct info is in the pinfo regardless.  It shouldn't
>>matter if CreateFileMapping or OpenFileMapping is called.
>
>Terminal paranoia. I am just worried that doing so on every fork may
>end up exposing an MS bug (you rightly wrote "shouldn't", not "doesn't").
>Also, there must be a critical section in the kernel. Letting Windows 
>decide in what order things are done may lead to more process switching
>than having Cygwin avoid the conflict. 

I wouldn't be surprised that there is not much difference between
CreateFileMapping and OpenFileMapping.  It's possible that OpenFileMapping
is more expensive than CreateFileMapping, given Microsoft.

More importantly, unlike the above "forked_pid" code, which is recent,
the logic flow for the rest of this stuff hasn't changed in a while so
I'm inclined not to rock the boat.

cgf