STDIN is buffered on any reasonable system, so unless you straight up discard UCI commands, you are (eventually) dealing with them. Taking a long time to respond may not be nice.
So how slow can you be? The UCI specification itself has no limits. Such limits would be up to the GUI.
You mentioned Cute Chess. While it may not be representative for all GUIs, Cute Chess limits should give you an idea of how fast you need to respond.
- Engine startup: 35 seconds
- Ping (
isready
): 15 seconds
- Quit: 5 seconds.
Making a reasonably functional single threaded engine, the second alternative, "While searching, pause and check stdin every so often" would be perfectly reasonable, "every so often" meaning some seconds.
stop
and go infinite
:
So what would "not implementing" these even mean? in the specification:
- stop
stop calculating as soon as possible,
"As soon as possible" could very well be to just wait for the search to finish. This is not great but it's still implementing the communication protocol. If you consider the GUI timing out the engine and killing it if you try to stop it as "play the engine reasonably", this would be okay.
Same for go infinite
. You could make your engine do a fixed length search, and then wait around for the corresponding stop
command. Not a great use of the potentially extra time available, but not a communication protocol violation. (note: A GUI would ignore bestmove
etc. in this move until it has sent a stop
)
Also, if I have two engines setup to play each other each given a time control, would they ever need to respond to stop, or would killing the engine be enough?
An engine vs. engine match can be set up without using the stop command. The engines can reply with bestmove
at their leisure, and it's up to the GUI to judge the games as lost on time and killing engines when they aren't needed anymore.