just a thought... prefix all async commands with "async_" so that it is clear. Also, that way there can be a version of the command that is async and one that blocks and an engine can support one or both. This could be useful for commands that query on state (or estimated score or whatever). An engine might not be able to easily support that async, but another engine might be able to. The controller can query using get_commands (or whatever the function is called) and know that it can call it anytime or only when the engine isn't thinking. Also, it would make it clearer how a command operates and a command can be assumed to be blocking unless it has that prefix and if we change the behavior of the async versions from the blocking ones an engine can still support both.
- Nick On 3/5/07, Eduardo Sabbatella <[EMAIL PROTECTED]> wrote:
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/
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
