[gtp] Re: [computer-go] GTPv3

[Weston Markham]

On 3/7/07, Paul Pogonyshev <pogonyshev at gmx.net> wrote:
> Gunnar Farneback wrote:
> > Example 3: Like example 2, but abort command comes too late.
...
> Maybe it should then read
>
> ?2 not in progress
>
> It also makes sense to forbid an async_genmove (or simple genmove for
> that matter) until the previous genmove/async_genmove has finished.
> The engine should just fail with a predefined error string; I think
> it is really cumbersome for the engine to try synchronization here and
> serves little purpose.
>
> Paul

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.

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?

Weston