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

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
One has to wait on a handle to the thread know that termination has
completed, for which the synchronise standard access right is
The same is true of Win32's TerminateProcess/ExitProcess, in turn
NtTerminateProcess, where one waits instead on a handle to the

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.

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.

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().

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.

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.


-- Problem reports: FAQ: Documentation: Unsubscribe info:

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