simon-git: putty (master): Simon Tatham

Fri Sep 25 16:11:35 BST 2015

TL;DR:
  431f8db Fix winhandl.c's failure to ever free a foreign handle.

Repository:     git://git.tartarus.org/simon/putty.git
On the web:     http://tartarus.org/~simon-git/gitweb/?p=putty.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2015-09-25 16:11:35

commit 431f8db86278836adbe63dba7d1ab25fb94b616d
web diff http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=commitdiff;h=431f8db86278836adbe63dba7d1ab25fb94b616d;hp=4df5d56f3df09398c1ffe8773c20cc4fecf3b102
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Sep 25 16:03:47 2015 +0100

    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.

 windows/winhandl.c |   21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)