Question to UCI engine authors

[hgm]

What commands must a UCI engine be able to handle during search, in particular search for thinking (as opposed to pondering)? I suppose the engine must always monitor input, to handle a 'stop' (or 'ponderhit') command. But can you send 'quit', or 'setoption' (e.g. for turning Ponder on or off) without stopping the search first? Will engines process such commands immediately, or will they just postpone them till the search has terminated?

I know that the UCI specs say the engine should be able to process stdin at any time, but what does 'process' mean here? Reading away a command while ignoring it (so that you remain sensitive to later commands) is also a form of processing. Some commands do not seem very suitable for executing during search. E.g. what would you do if you receive

setoption name Clear Hash

during thinking? Or a setoption that alters the number of search threads. Or the MultiPV setting. Are the new values just buffered, and only looked at when a new search starts? Is it OK to alter the Ponder option during thinking?

[mcostalba]

What commands must a UCI engine be able to handle during search, in particular search for thinking (as opposed to pondering)?

I think you should ask (mainly to yourself): is the GUI responsible for the action/data it sends to the engine? Or otherwise is the engine supposed to "sanitize" the input received from the GUI?

I think that the UCI protocol approach, although not explicit, but clear for me, is that the GUI _is_ responsible for what it sends to the engines and when. The engines should not try to sanitize the data from GUI, just execute it according to UCI protocol. The GUI is supposed to _understand_ what it sends to the engines and why.

[mar]

I always abort current search immediately whenever I receive setoption, which I consider the easiest thing to do.

I think the GUI should take care of such situations and stop the search or not allow to change options while engine is thinking.

[jdart]

Generally I divide both Winboard and UCI commands into two categories. One category if received during a search is executed immediately, and the other is deferred until the search completes.

For UCI all commands are executed immediately except "quit", "position" and "ucinewgame". Those set a flag for the search to stop and then after it has stopped they are executed.

I execute "setoption" during a search. I understand that "setoption" is not supposed to be sent during a search, but ChessBase (and Fritz?) at least send it anyway. So I do handle it then.

--Jon

[hgm]

Ah, I overlooked that. 'setoption' should not be sent while the engine is searching.

Unfortunately I did not anticipate this when defining an 'option' command for WB protocol. In analogy with the easy/hard commands for ponder off/on, and post/nopost for Thinking Output, which WinBoard would just send when the user would change them, whatever the engine was doing, I assumed other options should be treated similarly. I put the responsibilty to not require things that were obviously impossible to the user. But switching pondering (or engine output) while the engine is thinking doesn't seem so impossible. In UCI it requires a 'setoption', though.

So I guess a UCI2WB adapter should queue WB 'option' commands to a thinking engine, and only release them after the engine stopped thinking. Some commands should exert out-of-order power over the search, however. If a WB 'quit' or 'force' command comes in after a lot of other commands, it should still cause immediate termination of the search.

BTW, 'position' or 'ucinewgame' commands during a search (and apparetly 'setoption' too), without a 'stop' being sent first, seem a UCI violation to me. Wouldn't that fall under "commands that are not expected to come at this time should be ignored"?

[Fabio Gobbato]

During search I handle only "isready", "ponderhit" and "stop". Handle the options would add more complexity to the engine. It's better for the engine to receive the other commands while it's not searching.

[jdart]

I prefer not to ignore things the GUI sends. Deferring execution is better than ignoring IMO.

--Jon

[cdani]

Andscacs just processes anything it receives. If this implies that the engine will crash, it will crash. As Marco told, with UCI the GUI is responsible of everything.

I understand that the reasonable commands during a search are:
* isready
* stop
* quit
if I don't forget anything.

[hgm]

OK, based on all of your remarks I now adopted the following method in UCI2WB:

All 'simple' commands from the GUI, which merely set flags in the adapter (e.g. controlling the verbosity of the output, or draw offers) are always treated immediately. Commands that must send 'setoption' to the engine are also treated immediately, but when the engine is thinking the message for the engine is diverted to a memory buffer. When a ponder or analysis search is in progress, these searches are aborted by sending 'stop', and the message is sent to the engine immediately after that. When a 'bestmove' command is received from the engine, all commands in the memory buffer are sent to the engine.

Commands that would abort thinking (like 'quit') cause sending of a 'stop' command before they are treated in the normal way. This 'normal way' involves waiting for the search to finish before processing the command, (and then reading a new one). Apart from the commands that avoided the wait by aborting the search, these are mainly commands that could not possibly come during thinking (like an input move), or which by definition should be processed when the search terminates (like 'ping').

It seems this approach would prevent that any sequence of commands that could reasonably be sent during thinking would stall processing of commands, and thus mask a 'quit' command (which could lead to hanging engine processes if an impatient GUI then kills the adapter).