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 [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
