I just don't understand the benefit of using a control character as the
"break" code. If we agree that break is useful, then I think it should
be readable text like the rest of the GTP protocol. For example, the
word "abort". So if the server sends (the <id1> and <id2> are of course
optional):
<id1> genmove blah blah blah
// server waits a while, then decides it doesn't need the genmove
<id2> abort
It will get one of two things back. If the client can handle "abort",
and it gets the abort in time to cancel the genmove, then it will reply
with:
?<id1> aborted
=<id2> abort successful
If the client doesn't handle abort, or it doesn't get the abort command
in time, it will reply with something like:
=<id1> <genmove result>
?<id2> can't abort
There. Now much easier to see in logs, etc. Note that the server is
sending two text commands (genmove and abort) and it always gets two
responses, just like everything else in the GTP protocol. I don't see
any way that this would be harder than using a control character -
either way you need to use multithreading, signals, or polling to detect
the abort/control character.
Now, as for is this useful - I think it would be useful as an optional
command. If GTP was letting a user play the computer, the user may
decide to undo his move and play a different one - without abort, we
would need to wait for the computer to finish deciding its move before
it can recognize the undo and the alternate move and start coming up
with its response. With abort, it will be much more convienient to the
user.
Because it may be difficult to implement, and is not needed for most GTP
functionality, this command does have to be optional I think.
On Sat, 2002-10-26 at 03:01, gtp-request(a)lists.lysator.liu.se wrote:
Message: 1
Date: Fri, 25 Oct 2002 12:43:38 +0200 (CEST)
From: A van Kessel <Adriaan.van.Kessel(a)rivm.nl>
To: gtp(a)lists.lysator.liu.se
Subject: [gtp] interrupt
...
* so, ^C is a bad choice. Any suggestions for an alternative
interrupt character? ESC, DEL, ^A, ^G ^X ^T come to mind.
^G seems safe to me. Won't interfere with anything.
Does ring a bell, though ... Wake-up call!
* In addition, I think there is a place for a similar interrup-feature,
but using a signal (interrupt) instead of an in-band character.
It could use the same semantics, but a different command name
("signal", "interrupt" ?), making it's implementation independent
of the 003 feature.
This *could* be useful for engines that don't like polling
(but *do* support signals).