Hi,
On Tuesday 05 November 2002 09:23, A van Kessel wrote:
I still don't think we should allow the engine to return half-baked results when interrupted during genmove.
I agree.
I guess what Bill said is that if an engine wants to return half baked results after an interrupted genmove, it's up to the controller to decide whether it wants to use those results or discard them.
One thing is certain: we all agree that the state of the engine wrt those variables that are defined in GTP should **never** change if the command fails.
Either succeed or fail. Bill schubert's scheme is cleaner , IMO. wrt the ordering of commands and responses: there is nothing new here: if we treat abort like any other command, it's responses should come in the right order.
I agree. Abort should be treated as much as possible like the other commands. [...]
Counter-question to gunnar: would it be easyer to implement te abort command in Gnugo, if it were allowed to use a SIGINT instead ? (my guess is: yes)
I am nearly finished implementing "abort" with pthreads. I'll upload a version of Randyplus with pthreads & abort to ibiblio.org later tonight or tomorrow.
It's not a very clean implementation and as noted before, it's not much use for such a fast, simple engine as in Randyplus. But it works. And everybody is free and invited to look into the code and comment or improve.
What I found out with this exercise is: 1) It's not very costly in terms of code size, to add threads to a Go engine. 2) The engine should have two very clearly defined phases (first it thinks, second it commits the move to the data structures), for the "abort" to make any sense. 3) Adding "abort" does have a cost in terms of uniformity and elegance of the handling of GTP commands; in some cases this may be an acceptable trade-off. 4) Addings pthreads to a Go engine opens the door for many interesting developments...
Regards,