Both 'feature done=1' and 'uciok' are used to indicate termination of the option list, so in that sense they are equivalent. I was wrong though in stating there was no timeout period for 'uciok', though; it appears the UCI specs explicitly say there can be one. But this is also true for 'feature done=1', so again that is equivalence.Ras wrote: ↑Sat Jul 06, 2019 11:05 amNo, it isn't. "uciok" is only meant for acknowledging UCI mode, not for doing init. Therefore, "uciok" has to appear quickly after the GUI sent "uci", and lengthy init stuff is not allowed.
"isready" is meant as ping/pong replacement AND feature done with init, and the UCI spec explicitely mentions tablebase initialistion as example that may take some time. The engine only responds with "readyok" after it has processed the setoptions commands. The case where "isready" must be answered immediately is only after init and during search because then there is no reason why the engine should be hanging.
It is only the preceeding feature done=0 that alters the meaning of feature done=1 to also signal that the engine is done initializing, and allows you to make this last almost indefinitely.
But now that I think about it, neither 'feature done=1' nor 'uciok' are suitable for extending the initialization period. (Making those also equivalent in that respect.) The problem is that there is nothing to initialize at that time. Things like loading EGT or allocating huge hash tables can only be done after the GUI told the engine where to find the EGT, or how much hash to use. In UCI the GUI will only do this after receiving 'uciok', but in CECP it will also only send 'egtpath', 'memory' and 'cores' commands after receiving 'feature done=1', in the same bunch as the 'new' that directly follows it.
So it is really the 'pong' after 'new' that is the first opportunity for the engine to let the GUI know it struggles in obeying its settings, and is therefore equivalent to the 'readyok'.
The 'feature done=0' trick thus doesn't seem to be so useful anymore in the face of the protocol extensions for setting engine parameters. It can still be used for things like initializing a GPU and loading a neural network, though.
Trying to solve that would lead to a very awkward design: the GUI would have to reply instantly to the egt and memory features (well, it actually already does that for option features, so this is not yet too bad). But the engine has no way of knowing whether an 'egtpath' command will actually be sent: it might be running on a computer that has no EGT installed. So it must also use some timeout mechanism to decide that none will be coming, and that it is thus "ready initializing them', and can send 'feature done=1'. Of course having a command for "I don't have any EGTs for you' would solve that, but introducing new commands defeats the purpose of using done=1 for synchronization, as you might as well have defined a new synchronization command directy. (And there already is a suitable one: 'ping'.)