Author: Robert Hyatt
Date: 18:52:38 01/31/99
Go up one level in this thread
On January 31, 1999 at 20:21:53, James Long wrote:
>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
correct. when you do the cin >> that is basically a traditional read, disguised
in C++ trappings... but when there is no data, you block in the operating
system waiting on the input, so that thread/process doesn't execute a single
instruction until the return key is pressed...
that is fine, as you have done it. you don't need to adjust priorities at
all (if you can). Because as soon as you hit that 'return' you want that
process to wake up, parse the input, and notify the search engine...
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.