perhaps since every command is numbered we could have a command that tells the engine to abort a command by number. The engine can ofcourse reply with a failure if it already processed the command and can not abort it. Genmove still seems to be somewhat of an issue, but atleast this way defines clear behavior that will work well as long as engines don't take too long to replay to an abort with a success or failure.
On 3/8/07, Markus Enzenberger <[EMAIL PROTECTED]> wrote:
I am still frightened by your plans, how to permit asynchronous commands in GTP. Here are some remarks and questions: genmove is only one of many commands that the user might want to abort. We use GTP extension commands for starting life and death searches or other lengthy computations and many of them can be aborted at any time. Do you really want a sync and async version and a different abort command for each of them? Potentially every GTP command can be a candidate for aborting. If a controller provides support for engine-specific extension commands without specifically knowing what they do (like GoGui's Analyze Commands), there should still be a way to let the user send an abort request and let those commands abort that are able to. Why is it necessary that the async genmove returns an immediate response? - Markus _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
