X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RCVD_IN_HOSTKARMA_YE
X-Spam-Check-By:	sourceware.org
X-Forefront-Antispam-Report:	CIP:157.56.242.197;KIP:(null);UIP:(null);IPV:NLI;H:BL2PRD0512HT002.namprd05.prod.outlook.com;RD:none;EFVD:NLI
X-SpamScore:	-7
X-BigFish:	PS-7(zzbb2dI98dI9371Izz1de0h1202h1e76h1d1ah1d2ahzz17326ah186M8275bhz32i2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h1155h)
Message-ID:	<50D4BC2C.3070507@coverity.com>
Date:	Fri, 21 Dec 2012 14:44:44 -0500
From:	Tom Honermann <thonermann AT coverity DOT com>
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version:	1.0
To:	<cygwin AT cygwin DOT com>
Subject:	Re: Intermittent failures retrieving process exit codes
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>
In-Reply-To:	<CADSoG1tLsuMS8p-8z7z8PQBQQUtsHM20wD-KYZjnhgKj7JqOuA@mail.gmail.com>
X-OriginatorOrg:	coverity.com
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.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

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

- Raw text -