I think you are making this more complex than it needs to be:
* If the command completes before the engine gets the abort,
then the command succeeds and the abort fails. Commands which
happen instantly, like "quit" or "boardsize", the abort never
comes in time, so it's always the abort that fails. This makes
sense because the whole point of the abort is not to undo
things - instead, it is to get the GTP client to stop what it
is doing and start listening to commands from the server
again. Whether the client stops because it completed the
command (in which case the command returns success & the abort
returns an error) or because it has aborted the command (in
which case the command returns an error & the abort returns
success) doesn't matter.
* Since "abort" causes the previous command to fail (if the
abort succeeds), and the GTP spec says that a failed command
should not change the state of the engine, that does imply
that if you can't return to the original engine state, you
should continue working on the genmove then return an error
for the abort. This is fine with me, but if we explicitly say
that an aborted genmove can change the engine state that is
fine with me also; I don't see that it matters whether you
undo your engine state or not after an abort to a genmove. If
you can, fine, if you can't, fine, as long as these state
changes don't leave you with a broken engine! For example, in
a "genmove/abort/genmove", if you have worked out some
life&death situations in the first genmove, why not be able to
use them in the 2nd?
I do agree that abort needs to be 100% optional. That makes it easier;
anything you can't abort, just finish the command and error out the
abort. If you can't abort anything, just treat abort as an unrecognized
command. A server must treat abort as a "hint" that it doesn't care
about the output of the current command, so this "hint" is only needed
to save time, not needed for correctness.
On Mon, 2002-11-04 at 03:00, Andrew Derrick Balsa:
I have thought about implementing it in the various small "xxxplus" engines.
But I immediately hit a snag: it's quite obvious that the engine has to react
differently according to what it was doing when it receives the "abort" command. What should it do if it receives the "abort" just after it received
a "quit"? Or after receiving a "boardsize"?
Let's assume it can only receive an "abort" after it has received a "genmove"...
Should it "undo" anything it has done until now? What if it can't undo changes
to some data structures? Should it fail? But the spec says that any failed
command should not change the state of the engine...
I confess I gave up after a few minutes. Receiving an "abort", either as a
single character or as an (IMHO preferable) full word, in a separate thread,
is easy in Linux. Making the engine react in a consistent manner, compatible
with the rest of the GTP command set, would certainly require a lot of work.
Perhaps I am wrong and somebody can come up with an unambiguous one-paragraph
GTP spec for the "abort" command. I couldn't think of any way to do that. :-(
Regards,
--
Andrew D. Balsa
andrebalsa(a)mailingaddress.org