On 3/8/07, Don Dailey <[EMAIL PROTECTED]> wrote:
On Thu, 2007-03-08 at 12:27 -0500, Weston Markham wrote: I think I am confused.
I may be confused as well. I see that Paul has responded as well, but just in case this doesn't clear up on it's own:
So what you might get is this: 1. controller sends async_genmove 2. controller (after some period of time) sends abort. 3. engine responds to aysnc_genmove 4. engine responds to the abort search
...
Isn't this a race condition? I believe this should cause no problems because the controller can simply ignore the non-relevant response to genmove (it knows it send abort.) But I don't think that is what you are talking about.
I didn't think that this is what you were talking about, either, so now it is not clear to me what race condition you are worried about. What behavior in this example depends on the timing? (I see no constraint on the actual ordering of #2, and #3, but no matter what order they occur in, the engine's responses would be the same, wouldn't they? I assume, by the way, that #3 is the asynchronous response to #1, and not the initial synchronous one.) You are claiming that there is some case where this scenario violates some rule of Gunnar's proposed protocol, correct? (The proposal did not constrain the responses based on what additional commands had already been sent, but rather what other responses had already been sent.) What exactly is that violation? Weston _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
