This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Intermittent failures retrieving process exit codes


On 12/21/2012 07:15 AM, Nick Lowe wrote:
Briefly casting my eye at the test case, as a general point, remember
that these termination APIs all complete asynchronously and I do not
believe it has ever been safe or correct to call another while one is
still pending - you are in undefined, edge case behaviour territory
here.

These comments do not match my understanding of these APIs. MSDN documentation contradicts some of this as well.


Win32's TerminateThread/ExitThread, that in turn calls the native
NtTerminateThread, only requests cancellation of a thread and returns
immediately.
One has to wait on a handle to the thread know that termination has
completed, for which the synchronise standard access right is
required.
The same is true of Win32's TerminateProcess/ExitProcess, in turn
NtTerminateProcess, where one waits instead on a handle to the
process.

TerminateProcess() is documented to perform error checking and then to schedule asynchronous termination of the specified process. I would not be surprised if the asynchronous termination applies even when GetCurrentProcess() is used to specify the process to terminate, but I would likewise not be surprised if TerminateProcess() has special handling for this. I agree that calls to TerminateProcess() might return before the calling thread/process is terminated. I have not tried to verify this behavior though.


http://msdn.microsoft.com/en-us/library/windows/desktop/ms686714%28v=vs.85%29.aspx

The MSDN documentation for TerminateThread() does not state that the termination is carried out asynchronously, but I would not be surprised if that is the case.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686717%28v=vs.85%29.aspx

I would be *very* surprised if it is possible for ExitProcess() and ExitThread() to return (unless the thread is being suspended and its context manipulated by another process/thread). The MSDN docs for these do not mention any possibility of return. In addition, the ExitThread() documentation explicitly states that Windows manages serialization of calls to ExitProcess() and ExitThread().

<quote>
The ExitProcess, ExitThread, CreateThread, CreateRemoteThread functions, and a process that is starting (as the result of a CreateProcess call) are serialized between each other within a process. Only one of these events can happen in an address space at a time.
</quote>


http://msdn.microsoft.com/en-us/library/windows/desktop/ms682659%28v=vs.85%29.aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682658%28v=vs.85%29.aspx

I read that quote as supporting my assertion that the observed behavior is a defect in Windows. It appears Windows is failing to serialize the calls appropriately.

Tom.


-- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]