Treat 'quit', 'force' and '?' commands immediately
authorH.G.Muller <hgm@hgm-xboard.(none)>
Wed, 30 Nov 2016 08:02:50 +0000 (09:02 +0100)
committerH.G.Muller <hgm@hgm-xboard.(none)>
Wed, 30 Nov 2016 08:18:54 +0000 (09:18 +0100)
commit85a82d8e5887b236ac8c6bad257301b4d30b948d
tree1b072e2573a672b428a2025c91b318554fd13ad0
parente7c084cff327333c02190799fc3803c1a2b4fe74
Treat 'quit', 'force' and '?' commands immediately

The blocking of input during thinking made it also insensitive to 'quit'.
This would cause hanging engine processes when the GUI was closed and would
kill the adapter because it did not respond to 'quit' in time. The Sync()
call that waits for the engine's 'bestmove' is now deferred until after
reading input (executed conditionally through a 'think' flag, so that
it only happens during thinking), so that we can peek at the first command
that arrives during thinking. If it is one of the 'immediate' commands
(?, quit or force), a 'stop' command is sent to the engine before we
start waiting for the 'bestmove', which then never should take long.
 Draw offers could potentially arrive during thinking as well, interefering
with this mechanism by eclipsing a following ?/quit/force. As these would
just set the drawOffer flag for processing during the next move, these
are now fully processed immediately.
UCI2WB.c