]> asedeno.scripts.mit.edu Git - PuTTY.git/commit
Fix winhandl.c's failure to ever free a foreign handle.
authorSimon Tatham <anakin@pobox.com>
Fri, 25 Sep 2015 15:03:47 +0000 (16:03 +0100)
committerJacob Nevins <jacobn@chiark.greenend.org.uk>
Thu, 29 Oct 2015 09:27:54 +0000 (09:27 +0000)
commit98c946966b191031f4692a09147bc71d415e44c8
treedc8b64ba8f8d644eb7a11c4849413f050a9b7b0c
parent72b659cb728b1f549c49b40d37f59b870f006fac
Fix winhandl.c's failure to ever free a foreign handle.

Handles managed by winhandl.c have a 'busy' flag, which is used to
mean two things: (a) is a subthread currently blocked on this handle
so various operations in the main thread have to be deferred until it
finishes? And (b) is this handle currently one that should be returned
to the main loop to be waited for?

For HT_INPUT and HT_OUTPUT, those things are either both true or both
false, so a single flag covering both of them is fine. But HT_FOREIGN
handles have the property that they should always be waited for in the
main loop, but no subthread is blocked on them. The latter means that
operations done on them in the main thread should not be deferred; the
only such operation is cleaning them up in handle_free().

handle_free() was failing to spot this, and was deferring freeing
HT_FOREIGN handles until their subthread terminated - which of course
never happened. As a result, when a named pipe server was closed, its
actual Windows event object got destroyed, but winhandl.c still kept
passing it back to the main thread, leading to a tight loop because
MsgWaitForMultipleObjects would return ERROR_INVALID_HANDLE and never
block.

(cherry picked from commit 431f8db86278836adbe63dba7d1ab25fb94b616d)
windows/winhandl.c