hgm wrote:As the other posters also mentioned:
The UCI spec is such that 'isready/readyok' cannot be used to detect if an engine is done searching. The search leads its own life next to the command stream, and is controlled by the go/stop/bestmove dialog.
So the only way to verify 'stop' has been processed is to wait for the 'bestmove'. (No need to probe with isready after that, if you did not send any commands after 'stop'.)
Amazingly, in this case I agree.
Actually UCI protocol is correct, it just needs to be read very careful.
1) First of all 'stop':
Code: Select all
* stop
stop calculating as soon as possible,
don't forget the "bestmove" and possibly the "ponder" token when finishing the search
So it does not require search is stopped immediately and actually acknowledges that some info is sent even after stop, like bestmove (actually it must be sent after stop, otherwise engine is broken)
2) Then isready/readyok
Code: Select all
* isready
this is used to synchronize the engine with the GUI. When the GUI has sent a command or
multiple commands that can take some time to complete,
this command can be used to wait for the engine to be ready again or
to ping the engine to find out if it is still alive.
E.g. this should be sent after setting the path to the tablebases as this can take some time.
This command is also required once before the engine is asked to do any search
to wait for the engine to finish initializing.
This command must always be answered with "readyok" and can be sent also when the engine is calculating
in which case the engine should also immediately answer with "readyok" without stopping the search.
* readyok
This must be sent when the engine has received an "isready" command and has
processed all input and is ready to accept new commands now.
It is usually sent after a command that can take some time to be able to wait for the engine,
but it can be used anytime, even when the engine is searching,
and must always be answered with "isready".
There is no problem to send isready while searching and engine replies with readyok without affecting search in any way.
The use of isready is " to wait for the engine to be ready again or to ping the engine to find out if it is still alive" in which case engine replies with readyok. And this is exactly what SF does: after a stop command it is still alive and also ready to accept new commands. Actually SF can easily accept new commands after a stop has been sent and before bestmove is returned. SF can even accept a new 'go' command at any time after 'stop' and the new 'go' command will start a new search as soon as possible.
The UCI protocol, quite clearly IMO, states the synchronization with the stop shall be bestmove (just read 'stop' description). Instead readyok is used to tell the GUI that it can send new commands at anytime GUI wishes.