[PATCH 3 of 3] killdaemons: fix WaitForSingleObject() error handling logic on Windows

Matt Harbison mharbison72 at gmail.com
Thu Jun 15 23:58:49 EDT 2017


# HG changeset patch
# User Matt Harbison <matt_harbison at yahoo.com>
# Date 1497578382 14400
#      Thu Jun 15 21:59:42 2017 -0400
# Node ID f4df0165029314a36b3e798ea60b450e2868ce4e
# Parent  60b027e4e7b605ab59348ddb983e631fdf24e61e
killdaemons: fix WaitForSingleObject() error handling logic on Windows

The error return is not 0 for this method, so _check() was doing nothing when an
error occurred.  This forces the error path, much like the check for
OpenProcess().

The only unhandled return is now WAIT_ABANDONED, but I don't see how that could
happen in this case.

diff --git a/tests/killdaemons.py b/tests/killdaemons.py
--- a/tests/killdaemons.py
+++ b/tests/killdaemons.py
@@ -44,6 +44,7 @@
         SYNCHRONIZE = 0x00100000
         WAIT_OBJECT_0 = 0
         WAIT_TIMEOUT = 258
+        WAIT_FAILED = _DWORD(0xFFFFFFFF).value
         handle = ctypes.windll.kernel32.OpenProcess(
                 PROCESS_TERMINATE|SYNCHRONIZE|PROCESS_QUERY_INFORMATION,
                 False, pid)
@@ -56,8 +57,8 @@
                 pass # terminated, but process handle still available
             elif r == WAIT_TIMEOUT:
                 _check(ctypes.windll.kernel32.TerminateProcess(handle, -1))
-            else:
-                _check(r)
+            elif r == WAIT_FAILED:
+                _check(0)  # err stored in GetLastError()
 
             # TODO?: forcefully kill when timeout
             #        and ?shorter waiting time? when tryhard==True
@@ -67,8 +68,8 @@
                 pass # process is terminated
             elif r == WAIT_TIMEOUT:
                 logfn('# Daemon process %d is stuck')
-            else:
-                _check(r) # any error
+            elif r == WAIT_FAILED:
+                _check(0)  # err stored in GetLastError()
         except: #re-raises
             ctypes.windll.kernel32.CloseHandle(handle) # no _check, keep error
             raise


More information about the Mercurial-devel mailing list