Ras wrote:The fact that "?" doesn't have to be processed during search is actually a big Winboard selling point for single threaded midrange engines, like Dorpsgek or NG-Play. It's bad from the user's point of view, as seen in this thread, but it makes programming so much easier.
Agreed. Building a chess engine is difficult enough, and I consider it a good thing that in a first attempt the programmer doesn't have to dig into the problem of peeking pipes or multi-threading to get something that can work. Even if that goes at the expense of some user convenience. Interrupting thinking is something that would only be done on rare occasions anyway, and WinBoard is resistant to it if the engine uses ping (which does not require any special knowledge to implement).
Then how do you stop analysis?
They have a routine MustStop() that is called regularly during search, which peeks the pipe when analyzing or pondering, and reads the clock when thinking. Commands are then only interpreted after the search is aborted.
My newer engines do it properly, reading available input during search, parsing the command, and deciding if it can be processed immediately, or requires a search abort (leaving the command in the input buffer, so that it can be processed again after the search returns.
However, if "?" is not implemented during search, then it's a safe bet that "force" during search is not implemented either, for the very same reason.
Indeed. This is why WinBoard checks when the "force" command has been processed by issuing a "ping" afterwards, and is aware that this can take some time.
Which Arena doesn't do before sending "new", which is why it has no way to see that the move that finally comes must be from the old game.
On engines that do support "ping" this should be considered improper use of the protocol.
However, "ping" doesn't really solve the issue that the engine doesn't process the input at all. Even let's say just 10 seconds delay between "move now" and "engine actually moves" are unacceptable in terms of UIs. The other nasty thing is the variance of the delay, which is also unacceptable.
Well, the UI cannot be blamed for what the engine does. People would just notice that on some engines "move now" is not implemented. Tough luck.
That's why I think WB engines that don't announce support for analysis mode just have to be killed off instead of trying to abort. In this particular case, that's what "restart engines" would do.
The problem is that I never got killing off engines to work reliably under Windows. The Windows API function TerminateProcess() just doesn't seem to work reliably.
However, what's broken isn't engines that don't implement this optional command. What's broken is the protocol specification that hasn't made such an important and easy command mandatory.
"ping" should not be considered an optional command any more than other commands. All commands are intended to make things work well, and not implementing any of them will always cause some loss of functionality. That you can instruct the GUI not to send them, or even have to explicitly request it will send them, is just a mechanism to provide backward compatibility for the benefit of legacy engines. Which then suffer this loss of functionality. But that is considered better than crashing them by sending them commands they do not implement anyway.
Yes, that's what I'd expect. I thought more in terms of killing the process the really hard way, via process ID and OS kill API. Then the engine is started as a new process which has clean state.
Well, WinBoard tries that, for engines that do not terminate fast enough after receiving "quit". (Configurable through an option /delayAfterQuit.) But that often seems to have no effect on the engine at all, and if I do a tournament with buggy engines that tend to hang, it leaves many CPU-eating zombie processes on the machine. There is an external program pv.exe that can kill programs by name of their executable, and that seems to work reliably. WinBoard can be configured to call external commands after each game, and kill rogue engines that way. But it would not work with concurrency, where several instances of the same engine might be at work simultaneously. It is a real problem.
[Edit] I am not sure what you mean when you make a distinction between the new specs and the original specs. Are you referring to
http://hgm.nubati.nl/CECP.html ? At the moment this just has the status of a draft for cleaning up the specs, and I cannot exclude that it still needs some revision to fix errors. But in the description of the "ping" command there, it does say "[feature ping=1] should be considered mandatory to have a properly working engine".