Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Interrupting a search

Author: James Long

Date: 17:21:53 01/31/99

Go up one level in this thread


On January 31, 1999 at 17:32:56, Robert Hyatt wrote:

>On January 30, 1999 at 15:22:50, James Long wrote:
>
>>On January 30, 1999 at 14:13:55, James Robertson wrote:
>>
>>>On January 30, 1999 at 13:50:22, Will Singleton wrote:
>>>
>>>>On January 30, 1999 at 11:54:18, James Robertson wrote:
>>>>
>>>>>I am trying to add compatibility with Winboard to allow it to interrupt a
>>>>>search. I am looking at EXchess and Crafty's interrupt stuff, but it goes over
>>>>>my head. Could somebody explain what is happening? Thanks!
>>>>>
>>>>>James
>>>>
>>>>Do you mean that you can't stop a search when you receive a message from
>>>>winboard, or that you can't receive the msg while searching?
>>>>
>>>>Will
>>>
>>>I can't recieve a message from Winboard when I'm searching.
>>>
>>>James
>>
>>One solution is to spool off a thread to check for input.
>>If a (valid) user move is received, switch a global variable
>>to stop the pondering session (or set time_left if the
>>user made the predicted move and you haven't been pondering
>>long enough).
>>
>>Same goes for the regular search - when a valid command
>>is received that requires the program to stop searching,
>>switch that global variable (something like BOOL stop_search).
>>At every node, check for stop_search == TRUE.  If the
>>condition is true, return 0 to back down through the root.
>>
>>The trick to using threads is setting the proper
>>"priority," so that the input thread doesn't get any
>>more processor time than it needs.  This also renders
>>any same machine matches useless, but they're pretty
>>meaningless anyway. :-)
>>
>>
>>---
>>James
>
>
>'priority' ought not matter.  the 'input' thread should be blocked on a read,
>so that it can't execute anyway.  And in reality, you want the input thread to
>have a higher priority than the search thread or you would _never_ get it to
>execute and read a move... :)

I don't understand what you mean by "blocked on a read."
This is my simple thread:

void UIThread(void*)
{
   char usercommand[256];
   while (1) {
      cin >> usercommand;
      ParseInput(usercommand);
   }
}

Do you mean that the thread is not executing while waiting
for 'usercommand' ?

Is there a better way to do this?  Please elaborate...

---
James




This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.