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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: 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> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: coverity.com X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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(). 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. 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