Mail Archives: cygwin/2012/12/21/22:09:46
X-Recipient: | archive-cygwin AT delorie DOT com
|
X-SWARE-Spam-Status: | No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE
|
X-Spam-Check-By: | sourceware.org
|
MIME-Version: | 1.0
|
In-Reply-To: | <50D4BC2C.3070507@coverity.com>
|
References: | <50C2498C DOT 2000003 AT coverity DOT com> <50C276AC DOT 9090301 AT mailme DOT ath DOT cx> <50D401EF DOT 9040705 AT coverity DOT com> <20121221103241 DOT GD18188 AT calimero DOT vinschen DOT de> <CADSoG1tLsuMS8p-8z7z8PQBQQUtsHM20wD-KYZjnhgKj7JqOuA AT mail DOT gmail DOT com> <50D4BC2C DOT 3070507 AT coverity DOT com>
|
Date: | Sat, 22 Dec 2012 03:09:29 +0000
|
Message-ID: | <CADSoG1ta7A_G2jFMtgDoamF5pqimf_V=48O26SWAg994=vC7bw@mail.gmail.com>
|
Subject: | Re: Intermittent failures retrieving process exit codes
|
From: | Nick Lowe <nick DOT lowe AT gmail DOT com>
|
To: | Andrey Repin <cygwin AT cygwin DOT com>
|
X-IsSubscribed: | yes
|
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm
|
List-Id: | <cygwin.cygwin.com>
|
List-Unsubscribe: | <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
|
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com>
|
List-Archive: | <http://sourceware.org/ml/cygwin/>
|
List-Post: | <mailto:cygwin AT cygwin DOT com>
|
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
|
Sender: | cygwin-owner AT cygwin DOT com
|
Mail-Followup-To: | cygwin AT cygwin DOT com
|
Delivered-To: | mailing list cygwin AT cygwin DOT com
|
The documentation in MSDN is incorrect/incomplete with regards to
TerminateThread/TerminateProcess, both are definitely asynchronous.
I am not clear/confident on the behaviour of ExitProcess and
ExitThread, but will investigate with IDA and a test case later. I
suspect any locking/serialisation will pertain to these functions
only.
On Fri, Dec 21, 2012 at 7:44 PM, Tom Honermann <thonermann AT coverity DOT com> wrote:
> 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
>
--
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
- Raw text -