On Mon, Mar 05, 2007 at 09:50:30AM -0300, Eduardo Sabbatella wrote: > Actually gen_move blocks because every engine uses the > same thread for both the engine and the comm link.
Yes. That is not a bug, it is a feature, when using GTP for debugging, automatic tests, or something else that is based on scripts. As has been said before, it would be possible to add a command like 'start-thinking', which would return quickly, while the engine would be thinking in the background. While in this state, more asynchrnous commands could be issued. Perhaps the engine could also send status responses and/or chat messages without a status request. If an engine (or controller) does not support the new commands, they can always fall back to the old, synchronous, commands. > If the engine doesn't support "realtime" gtp, they > will be answer after the gen_move response. one at a > time. I think it would be better to create new commands, and leave genmove as it is, for maximizing the compatibility with old programs, and with new ones that haven't got around to implementing the asynch stuff yet. - Heikki -- Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
