Weston wrote: > Although Gunnar specifies async_genmove to return zero or one > responses, I believe that it may be more useful to allow it to return > any number. This allows the possibility for the controller to update > a "current best" display while it has still not accepted a single > definitive response. From the controller's point of view, the command > could still be in effect until a response to the abort_async_genmove > has been received. (although perhaps end_async_genmove would be more > appropriate name in this case.) I don't feel strongly either way on > this, but I thought that I should mention the possibility.
It's cleaner to have async_genmove return at most one move and let updates of current best move, significant changes of a principal variation, or other interesting information be asynchronous responses to some other command enabling that information. > Does it also make sense to forbid commands that modify the engine's > state? If the board state changes before async_genmove generates a > response, to which board does the response apply? It should of course apply to the state when the async_genmove was requested, but indeed it doesn't make sense to try to change the state under the feet of the engine. Either it could be forbidden or the engine could choose to block on state changing commands until the move generation is ready. /Gunnar _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
