Let engine thread parse difficult commands
commit33b016e152d6f441cc4b2d7c5cb8ad440f480bc6
authorH.G.Muller <hgm@hgm-xboard.(none)>
Sat, 8 Dec 2018 11:00:48 +0000 (8 12:00 +0100)
committerH.G.Muller <hgm@hgm-xboard.(none)>
Sat, 8 Dec 2018 11:42:56 +0000 (8 12:42 +0100)
treee1bd24aa91d6b2e645dc38a168283bf79311cfcb
parenta7d1a64029687fd9ae404f0d7490e3bac8c69fb7
Let engine thread parse difficult commands

The design of the adapter is completely changed: the engine thread is
made responsible for parsing and execution of all commands that cannot
be processed during a search. To this end it alternates between reading
from the engine (while the engine is searching, or should respond to a
'uci' or 'isready' query) and from the command queue (which is emptied
before we dedicate to relaying ponder output). Searches are terminated
by the GUI thread when a command arrives that would interrupt the search,
so that the engine thread will start looking at the command queue again.
  Syncing threads to wait for an engine reply is replaced by just doing
a (blocking) read for engine output in the same threat, and having the
processing routine return once the answer has arrived (and is processed).
Instead the Sync pipe is now used to block reading of the command queue
when this is empty.
  This change breaks several of the less elementary commands.

Fix command queue
UCI2WB.c