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?
Question to UCI engine authors
Moderators: hgm, Rebel, chrisw
-
- Posts: 27795
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: Question to UCI engine authors
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?hgm wrote:What commands must a UCI engine be able to handle during search, in particular search for thinking (as opposed to pondering)?
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.
-
- Posts: 2555
- Joined: Fri Nov 26, 2010 2:00 pm
- Location: Czech Republic
- Full name: Martin Sedlak
Re: Question to UCI engine authors
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.
I think the GUI should take care of such situations and stop the search or not allow to change options while engine is thinking.
-
- Posts: 4366
- Joined: Fri Mar 10, 2006 5:23 am
- Location: http://www.arasanchess.org
Re: Question to UCI engine authors
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
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
-
- Posts: 27795
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Question to UCI engine authors
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"?
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"?
-
- Posts: 217
- Joined: Fri Apr 11, 2014 10:45 am
- Full name: Fabio Gobbato
Re: Question to UCI engine authors
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.
-
- Posts: 4366
- Joined: Fri Mar 10, 2006 5:23 am
- Location: http://www.arasanchess.org
Re: Question to UCI engine authors
I prefer not to ignore things the GUI sends. Deferring execution is better than ignoring IMO.
--Jon
--Jon
-
- Posts: 2204
- Joined: Sat Jan 18, 2014 10:24 am
- Location: Andorra
Re: Question to UCI engine authors
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.
I understand that the reasonable commands during a search are:
* isready
* stop
* quit
if I don't forget anything.
Daniel José - http://www.andscacs.com
-
- Posts: 27795
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Question to UCI engine authors
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).
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).