Answers.Body: <p>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 <em>nice</em>.</p>
  <p>So how slow can you be? The <a href="https://www.shredderchess.com/download/div/uci.zip" rel="nofollow noreferrer">UCI specification itself</a> has no limits. Such limits would be up to the GUI.</p>
  <p>You mentioned Cute Chess. While it may not be representative for <em>all</em> GUIs, <a href="https://github.com/cutechess/cutechess/blob/master/projects/lib/src/chessengine.cpp" rel="nofollow noreferrer">Cute Chess limits</a> should give you an idea of how fast you need to respond.</p>
  <ul>
  <li>Engine startup: 35 seconds</li>
  <li>Ping (<code>isready</code>): 15 seconds</li>
  <li>Quit: 5 seconds.</li>
  </ul>
  <hr />
  <p>Making a reasonably functional single threaded engine, the second alternative, &quot;While searching, pause and check stdin every so often&quot; would be perfectly reasonable, &quot;every so often&quot; meaning some seconds.</p>
  <p><code>stop</code> and <code>go infinite</code>:</p>
  <p>So what would &quot;not implementing&quot; these even mean? in the specification:</p>
  <blockquote>
  <ul>
  <li>stop<br />
  stop calculating as soon as possible,</li>
  </ul>
  </blockquote>
  <p>&quot;As soon as possible&quot; could very well be to just wait for the search to finish. This is not <em>great</em> 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 &quot;play the engine reasonably&quot;, this would be okay.</p>
  <p>Same for <code>go infinite</code>. You could make your engine do a fixed length search, and then wait around for the corresponding <code>stop</code> command. Not a great use of the potentially extra time available, but not a communication protocol violation. (note: A GUI would ignore <code>bestmove</code> etc. in this move until it has sent a <code>stop</code>)</p>
  <blockquote>
  <p>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?</p>
  </blockquote>
  <p>An engine vs. engine match can be set up without using the stop command. The engines can reply with <code>bestmove</code> 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.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-17T23:21:02.080Z
Answers.Text: Thanks for the thorough answer.
Answers.UserDisplayName: qwr
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-17T21:57:01.413Z
Answers.LastActivityDate: 2022-09-17T21:57:01.413Z
Answers.UserDisplayName: SE - stop firing the good guys
Body: <p>According to the UCI protocol, an engine implementing UCI should always be able to respond to stdin. I thought of two ways to accomplish this in an engine of my own:</p>
  <ul>
  <li>Implement threads like Stockfish does, so search can be interrupted</li>
  <li>While searching, pause and check stdin every so often</li>
  </ul>
  <p>However I checked Sunfish's implementation and it seemingly doesn't bother implementing this (commands like <code>stop</code> and <code>go infinite</code>), yet it can still play on Lichess as a bot. This would obviously simplify my toy engine a lot. So is it necessary to implement these to be able to play the engine reasonably with a GUI like Cute Chess? Also, if I have two engines setup to play each other each given a time control, would they ever need to respond to <code>stop</code>, or would killing the engine be enough?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-09-13T05:45:15.783Z
Comments.Text: @user30536 clearly I'm not going for a full UCI implementation if I can get away with it. The question is, can I get away with it.
Comments.UserDisplayName: qwr
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-09-13T17:54:08.677Z
Comments.Text: well I really don't want to implement threads or multiprocessing in python and I'm not sure how fast GUIs expect engines to respond. ex. Is responding in 0.5 sec considered responsive enough
Comments.UserDisplayName: qwr
Tags: <engines><uci><arena><cutechess>
Title: Can an engine function implementing UCI except without always reading stdin?
ThreadText: # Can an engine function implementing UCI except without always reading stdin?
  
  (Asked by: username_0 on 2022-09-12)
  
  According to the UCI protocol, an engine implementing UCI should always be able to respond to stdin. I thought of two ways to accomplish this in an engine of my own:
  
  * Implement threads like Stockfish does, so search can be interrupted
  * While searching, pause and check stdin every so often
  
  However I checked Sunfish's implementation and it seemingly doesn't bother implementing this (commands like `stop` and `go infinite`), yet it can still play on Lichess as a bot. This would obviously simplify my toy engine a lot. So is it necessary to implement these to be able to play the engine reasonably with a GUI like Cute Chess? 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?
  
  **Tags:** engines, uci, arena, cutechess
  
  > **Comments:**
  > **username_0**: @user30536 clearly I'm not going for a full UCI implementation if I can get away with it. The question is, can I get away with it.  
  > **username_0**: well I really don't want to implement threads or multiprocessing in python and I'm not sure how fast GUIs expect engines to respond. ex. Is responding in 0.5 sec considered responsive enough  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2022-09-17. Score: 0 | Accepted answer
  
  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](https://www.shredderchess.com/download/div/uci.zip) 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](https://github.com/cutechess/cutechess/blob/master/projects/lib/src/chessengine.cpp) 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.
  
  > **Comments:**
  > **username_0**: Thanks for the thorough answer.  
  
  ---
  
  