| commit | ca572d12c5d3fa4886b9e899dfc0680a73af2a82 | |
| author | H.G.Muller <hgm@hgm-xboard.(none)> | |
| Fri, 21 Dec 2018 15:26:51 +0000 (21 16:26 +0100) | ||
| committer | H.G.Muller <hgm@hgm-xboard.(none)> | |
| Fri, 21 Dec 2018 15:26:51 +0000 (21 16:26 +0100) | ||
| tree | e3c0bda089b2bae4824c3be6e097f11300fbf644 | treesnapshot (tar.gz zip) |
| parent | d4dcf61c68a94ebc18d8d2fc771c27751cd085d5 | commitdiff |
Suppress 2nd isready handshake on spurious 'new'
The feature reuse=0 should limit the number of 'new' commands to one.
But unfortunately XBoard under some conditions sends a spurious second
game-start sequence before it quits a reuse=0 engine to start a new
instance. This caused (non-compliant) engines that do not always respond
to 'isready' (a disease especially common with USI) to dodge the 'quit'
command, which then caused hanging engine processes after the adapter was
killed. Only the first 'new' command in every run now uses 'isready',
so the 'quit' command that follows a spurious 2nd 'new' can be relayed
without delay.
The feature reuse=0 should limit the number of 'new' commands to one.
But unfortunately XBoard under some conditions sends a spurious second
game-start sequence before it quits a reuse=0 engine to start a new
instance. This caused (non-compliant) engines that do not always respond
to 'isready' (a disease especially common with USI) to dodge the 'quit'
command, which then caused hanging engine processes after the adapter was
killed. Only the first 'new' command in every run now uses 'isready',
so the 'quit' command that follows a spurious 2nd 'new' can be relayed
without delay.
| UCI2WB.c | diffblobblamehistory |