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
