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 <[EMAIL PROTECTED]> 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@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 _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
