UCI , What command should the engine expect while it's searc

[MahmoudUthman]

If the engine is searching a position should it always expect the "stop" followed by "isready" command before sending another "Position" command ?
also I don't know much about C++ threading so I've decided to keep the search and a main UCI loop on the main thread and launch a secondary thread to listen for input during search what are all the possible commands that could be received during a search and is there any drawbacks to this approach "my engine is of course single threaded "?

[cdani]

If the engine is searching a position should it always expect the "stop" followed by "isready" command before sending another "Position" command ?

Also I don't know much about C++ threading so I've decided to keep the search and a main UCI loop on the main thread and launch a secondary thread to listen for input during search what are all the possible commands that could be received during a search and is there any drawbacks to this approach "my engine is of course single threaded "?

At position command, in Andscacs I stop wathever search is running. So I don't let it crash on strange order of commands.

Should be no drawbacks with a secondary thread if this one does not occupy any significative time of process, to avoid any interference with other processes.

About the commands during the search, taking care of stopping the search when necessary, you should be able to manage well the protocol.

[hgm]

If the engine is searching a position should it always expect the "stop" followed by "isready" command before sending another "Position" command ?

The 'isready' command can come at any time, but is always optional except for the first time, between 'uciok' and the first position-go. The engine should always be sensitive to 'stop', even when doing a timed search.

Note that in particular it makes little sense for a GUI to send an 'isready' after 'stop'. The 'stop' will always be acknowledge by a 'bestmove' response, so there is no need to monitor its completion. The 'readyok' response won't wait for the stop to be completed anyway. So after sending

stop
isready

you can very well get the resonse

readyok
bestmove e2e4

[MahmoudUthman]

thank you both , one more thing does the protocol guarantees that "stop" will be send before any other command other that "isready" if the engine is searching or could the GUI send something like "quit" while the engine is searching without sending stop , and after the GUI sends stop will it always wait for the best move response before sending another command ? "I thought that the GUI doesn't have to wait for acknowledgment, for example if you change the options while the engine is searching in arena it sends the "set option" command while the search is running"

[Ferdy]

thank you both , one more thing does the protocol guarantees that "stop" will be send before any other command other that "isready" if the engine is searching

If the engine is pondering a "ponderhit" command can be expected.

Code: Select all

* ponderhit
	the user has played the expected move. This will be sent if the engine was told to ponder on the same move
	the user has played. The engine should continue searching but switch from pondering to normal search.

or could the GUI send something like "quit" while the engine is searching without sending stop ,

That is possible based from the following.

Code: Select all

* quit
	quit the program as soon as possible

The engine is given time to exit cleanly when it says "as soon as possible".

and after the GUI sends stop will it always wait for the best move response before sending another command ?

Normally the gui would wait based from the following.

Code: Select all

* stop
	stop calculating as soon as possible,
	don't forget the "bestmove" and possibly the "ponder" token when finishing the search

The word bestmove would signal the GUI that the engine has stopped searching.

"I thought that the GUI doesn't have to wait for acknowledgment, for example if you change the options while the engine is searching in arena it sends the "set option" command while the search is running"

I have tried Arena 3.5.1 and it does not do it.

Normally when engine is searching and you try to configure it, the OK button is disabled.



But of course you can forcefully send a command to the engine under Arena, but in this case it is not Arena that sent it but the user.

[MahmoudUthman]

"I thought that the GUI doesn't have to wait for acknowledgment, for example if you change the options while the engine is searching in arena it sends the "set option" command while the search is running"

I have tried Arena 3.5.1 and it does not do it.

Normally when engine is searching and you try to configure it, the OK button is disabled.



But of course you can forcefully send a command to the engine under Arena, but in this case it is not Arena that sent it but the user.

I reached the common UCI options by right clicking over the clock/engine area and selecting configure engines , changing an option there say max cores sends the command right away even if the engine is running , but from what you've shown me this seems like a bug instead of being allowed by the UCI protocol, right ?

[Ferdy]

"I thought that the GUI doesn't have to wait for acknowledgment, for example if you change the options while the engine is searching in arena it sends the "set option" command while the search is running"

I have tried Arena 3.5.1 and it does not do it.

Normally when engine is searching and you try to configure it, the OK button is disabled.



But of course you can forcefully send a command to the engine under Arena, but in this case it is not Arena that sent it but the user.

I reached the common UCI options by right clicking over the clock/engine area and selecting configure engines , changing an option there say max cores sends the command right away even if the engine is running , but from what you've shown me this seems like a bug instead of being allowed by the UCI protocol, right ?

Right.