My attempt to summarise some of the points of discussion
wrt the gtp-interrupt-feature:
*) One-character (^C) vs full-command ("abort") interrupt.
We seem to agree that this is a non-issue.
This involves only the difference between one-
character lookahead vs word- line- or bigger lookaheads.
For the implementation, the size of the lookahead buffer
is less important than the lookahead per se, since that
will require the program to use some kind of polling,
threading, or event-driven input.
(a related issue, the signal-style interrupt has
already been abandoned)
*) The dialog-style of the command.
Bill Schubert's approach produces the cleanest
interface: the interrupt command should behave just like any
normal command, so the program should report separate results
for both the interrupted command and the interrupt command
itself. Both of them can either succeed or fail, seemingly
independently.
*) Semantics.
*) should the aborted command ("genmove", in most cases) report
the best move found sofar ?
*) if so, should it also have "committed" the move to
it's internal state ?
*) if it doen not have any move yet, what should the reply be ?
*) should the abort also undo the aborted command's side-effects ?
Personally, I think the aborted command should return an error,
and not some partial result. This will keep most of the
semantics out of the protocol.
a New proposal:
Maybe a separate command could be introduced to query the
best move post-abortum, but this could also introduce some fuzzy
semantics.
I could live with the following dialog
<1 genmove B
<2 abort
>?1 aborted
<=2 abort successful
<3 report_post_abortum_move
>=3 B E4
<4 play B E4
=4 Ok
Of course, both abort and report_post_abortum_move are optional
commands are optional and their presence can be verified with
the valid_command command.
For the report_post_abortum_move command, IMO it should either
succeed and report exactly one move, or fail with an appropriate
error message. ("no move available" or "not implemented" seem to
be the only plausible errors)
WRT the atomicity of other commands than genmove[Andrew Balsa]:
IMO, We cannot implicitly expect implementations to support full undo.
Allowing abortion of *any* command(reset,boardsize,quit, undo ...)
without full undo would make no sense. The engine would be left
in an undetermined state, and a reset/boardsize command would be
the only way out, anyway.
If the command (boardsize, quit, undo) cannot be undone, the cheapest
way for the implementation would be to just ignore the abort
, execute the command anyway, report it's success or error,
and report "nothing to abort" or "can't abort" for the abort command.
This will allow the driver program to blindly trust the
error/success reply.
(most commands will have completed execution before seeing the
abort command, so the abort would fail, anyway)
AvK