[computer-go] GTPv3

[Eduardo Sabbatella]

We got consensus :-)

Yes some messages are async, some are synqued. If an
async message/reply is received in the wrong time, it
could be ignored as they use to be information only
values, no state change of the game.

cool :-)

--- Don Dailey <drd at mit.edu> escribió:

> I agree with you.  My idea is to not have a specific
> aync
> command, but to have anycronous versions of
> commands.   The
> engine is free to accept or reject them.   Having an
> async
> command doesn't do anything if you haven't
> implemented the
> useful needed extensions.    Of course it could
> change the
> meaning of existing commands but I think it's
> cleaner to
> simply have new GTP commands that are understood to
> be
> asyncrounous.
> 
> Even UCI doesn't allow the engine to say anything it
> wants
> whenever it wants.   It is still semi-syncronous.  
> All
> communication sent from an engine is still a
> response to
> some command sent from the controller.   The rule is
> that
> you ignore any communication sent out of context and
> this avoids syncronization issues such as when the
> controller
> says to stop searching but the engine sends a move
> before
> this is noticed.  
> 
> So it's really not as complicated as you might
> think.  
> 
> "chat" I assume is about informational messages from
> a
> searching engine.   So it's a legitimate response to
> an asyncronous command to search a position, but if
> you are not searching a position it would be ignored
> by the controller.
> 
> Abort is the same,  it really means "stop searching
> if you are currently searching"  and so is ignored
> if
> you happen to have stopped at  almost the same 
> instant you recieved the command.
> 
> - Don
> 
>  
> 
> 
> 
> On Mon, 2007-03-05 at 09:08 -0300, Eduardo
> Sabbatella wrote:
> > Just an small thought
> > 
> > GTP could implement "async" commands. Adding
> commands
> > like: 
> > CHAT
> > ABORT
> > etc.
> > 
> > Its up to the engine to read them as soon as
> possible,
> > or wait to read/process them after processing a
> > get_move command.
> > 
> > I think just adding a couple of new commands that
> some
> > engines could implement them 'in real time' its
> good
> > enough for everybody.
> > 
> > I wouldn't add complexity adding a true async
> channel,
> > out of band or whatever.
> > 
> > I mean, commands are ordered, as before, as
> always,
> > that wouldn't break current implementations.
> > 
> > 
> > By the way, I use a lot of stderr, I love it for
> > debuging purposes, please don't use it as a second
> > stream of comunication with the engine. 
> > 
> > With stdin/out and a thread with a couple of
> mutexes
> > is all you need. (or thread safe queues if you
> like)
> > 
> > 
> > My 2 cents 
> 
> _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
>
http://www.computer-go.org/mailman/listinfo/computer-go/
> 



	

	
		
__________________________________________________ 
Preguntá. Respondé. Descubrí. 
Todo lo que querías saber, y lo que ni imaginabas, 
está en Yahoo! Respuestas (Beta). 
¡Probalo ya! 
http://www.yahoo.com.ar/respuestas