Re: [gnugo-devel] Thinking on opponent's time?

[Dave Denholm]

Allan Crossman <address@hidden> writes:

> >This could be implemented entirely in the GTP controller, without
> >changing GNU Go at all.
> 
> How would this work? Although the GTP controller could tell GnuGo to
> generate a move for its opponent, then look at that position, if the
> opponent's actual move comes in while GnuGo is spending time on some other
> move, the GTP controller will have to wait until GnuGo is finished looking
> at that, before it can tell it to look at the actual move. Isn't that so?

Yeah, that struck me. But the controller could spawn a second gnugo and
feed it the position. Then if a move comes in, it can just kill the second
one and speak to the first one.


Or if the controller has a network of machines available, it can
- ask one spare engine for the opponents likely moves
- feed one each to all available engines, asking how they would
  respond to each one.

But that still has the problem of how to cancel requests.
If the network is such that engines are spawned by inetd on
a connection, then maybe the multiplexing controller can cancel
the request just by closing the socket. Then a new engine will
spring into life when the controller connects to the machine
again.



Maybe it would help if there was a way to interrupt gtp commands.
On unix, one way would be for the engine to fork() a child, and
then wait for a message from either controller or child. If a message
comes from controller, it kills the child. Else it forwards the response
from the child to the controller.


dd
-- 
address@hidden          http://www.insignia.com