On 9/29/2012 12:02 PM, Bill Meier wrote:
On 9/29/2012 11:49 AM, cmaynard@xxxxxxxxxxxxx wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=45212
User: cmaynard
Date: 2012/09/29 08:49 AM
Log:
Revert most of r45210. We don't use the return value of
GetExitCodeProcess(), but it still needs to be called to get childstatus.
Looking at
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683189%28v=vs.85%29.aspx
[1]
Two comments:
1. I suspect that testing 'childstatus' may not be valid if
getExitCodeprocess returns FALSE;
2. I don't understand the 'Important' para in the 'Remarks' section.
The first para under 'Remarks' and the 'Important' para seem to
contradict each other (altho the first para uses 'process' and the
'Important' para uses 'thread').
Not being a Windows API programmer, I'll leave this to others ....
Bill
[1]
Remarks
This function returns immediately. If the process has not terminated and
the function succeeds, the status returned is STILL_ACTIVE. If the
process has terminated and the function succeeds, the status returned is
one of the following values:
The exit value specified in the ExitProcess or TerminateProcess
function.
The return value from the main or WinMain function of the process.
The exception value for an unhandled exception that caused the
process to terminate.
Important The GetExitCodeProcess function returns a valid error code
defined by the application only after the thread terminates. Therefore,
an application should not use STILL_ACTIVE (259) as an error code. If a
thread returns STILL_ACTIVE (259) as an error code, applications that
test for this value could interpret it to mean that the thread is still
running and continue to test for the completion of the thread after the
thread has terminated, which could put the application into an infinite
loop.
Now I get it.
... an *application* should not use ...
So: maybe the only issue is whether the return TRUE/FALSE value can be
ignored (as the code has obviously been doing for quite some time).
