[PATCH]: broken pipe
Pierre A. Humblet
Mon Aug 30 23:28:00 GMT 2004
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.
>>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.
More information about the Cygwin-patches