simon-git: putty (master): Simon Tatham

[Commits to Tartarus CVS repository.]

TL;DR:
  7d97c2a Stop Windows PuTTY becoming unresponsive if server floods us.

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-03-07 17:15:23

commit 7d97c2a8fdb745905fd61a9ce4abbf822e167cef
web diff http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=commitdiff;h=7d97c2a8fdb745905fd61a9ce4abbf822e167cef;hp=06d2fb5b372ff076d5e339f5baa3d919cb48870f
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Mar 7 17:10:36 2015 +0000

    Stop Windows PuTTY becoming unresponsive if server floods us.
    
    This was an old bug, fixed around 0.59, which apparently regressed
    when I rewrote the main event loop using the toplevel_callback
    mechanism.
    
    Investigation just now suggests that it has to do with my faulty
    assumption that Windows PeekMessage would deliver messages in its
    message queue in FIFO order (i.e. that the thing calling itself a
    message queue is actually a _queue_). In fact my WM_NETEVENT seems to
    like to jump the queue, so that once a steady stream of them starts
    arriving, we never do anything else in the main event loop (except
    deal with handles).
    
    Worked around in a simple and slightly bodgy way, namely, we don't
    stop looping on PeekMessage and run our toplevel callbacks until we've
    either run out of messages completely or else seen at least one that
    _isn't_ a WM_NETEVENT. That way we should reliably interleave NETEVENT
    processing with processing of other stuff.

 windows/window.c |   24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)