Winboard Forum

Hi all,
I?m just trying to fix a problem that occurs when my engine is used in console mode. I tried to solve some simple mate positions and observed that the engine kind of stopps when I change to another application and then switch back to the console where the engine is (or better should) be calculating. I can continue (note it?s continue and not restarting) the calculation by pressing enter in the console and the calculation continues where it stopped. It?s not only a delayed output as the taskmanager shows that the engine powers down completely. Assuming that the problem is somehow related to my checkinput() function I changed the checkinput() function to use kbhit() when in console mode instead of using the bioskey() stuff which depends on the windows api. Still the problem remains.
Any ideas what I?m doing wrong? Maybe it?s just a compiler switch I?m missing ?

Best regards
Roman

checkinput() looks like that:

Code: Select all

int check_input()
{
   int data, bytes;
   char input[255]="", *endc;
   char c;

   setbuf(stdout, NULL);
   setbuf(stdin, NULL);

   data = 0;
   /* console stuff */
   if (CONSOLE && kbhit()) {

      c = getche();

      if (c == 'q' || c == 'Q')
      {
         search_time = 0;
         return 1;
      }
      else
         return 0;
   }
   /* winboard, UCI part */
...


checkinput() is called from the search:

Code: Select all

...
   --checknodes;
   if (checknodes < 0) {
      in = 0;

      in = check_input();

      if (clock() + 50 > search_time || in == TRUE) {
         exit_search = 1;
         return alpha;
      }
      checknodes = 1024;
   }
...


This is a really common problem and many chess engines have the same behavior.

I think that probably the best solution is to have a separate i/o thread that does all the reading and writing.

Dann Corbit wrote:This is a really common problem and many chess engines have the same behavior.

I think that probably the best solution is to have a separate i/o thread that does all the reading and writing.

Thanks Dann!
Thought this behaviour would indicate some kind of bug. Guess I will put that on my todo list then as I have some other things to fix as well and diving into Posix stuff doesn't sound like a lot of fun to me

Roman

Roman Hartmann wrote:

Dann Corbit wrote:This is a really common problem and many chess engines have the same behavior.

I think that probably the best solution is to have a separate i/o thread that does all the reading and writing.

Thanks Dann!
Thought this behaviour would indicate some kind of bug. Guess I will put that on my todo list then as I have some other things to fix as well and diving into Posix stuff doesn't sound like a lot of fun to me

Roman

I have uploaded a template for an input thread. It is a cut out from Alaric with only the thread stuff left and a faked search to illustrate the 'stop' and 'quit' during search. No special need for knowledge about threading - just a few hints that I put in the readme file. Also note that this template is C++ but by replacing the cout commands with printf or similar it will compile as pure C-code.
Template download

Have fun
/Peter

Peter Fendrich wrote:
I have uploaded a template for an input thread. It is a cut out from Alaric with only the thread stuff left and a faked search to illustrate the 'stop' and 'quit' during search. No special need for knowledge about threading - just a few hints that I put in the readme file. Also note that this template is C++ but by replacing the cout commands with printf or similar it will compile as pure C-code.
Template download

Have fun
/Peter

Hi Peter,
thanks a lot for that! So Roce might get rid of that unwanted feature earlier than I expected. Dealing with these input/output stuff under windows gave my quite some headache as I had to rely on some functions I never heard of and the program still showed some odd behaviour.

Roman

Roman Hartmann wrote:

Peter Fendrich wrote:
I have uploaded a template for an input thread. It is a cut out from Alaric with only the thread stuff left and a faked search to illustrate the 'stop' and 'quit' during search. No special need for knowledge about threading - just a few hints that I put in the readme file. Also note that this template is C++ but by replacing the cout commands with printf or similar it will compile as pure C-code.
Template download

Have fun
/Peter

Hi Peter,
thanks a lot for that! So Roce might get rid of that unwanted feature earlier than I expected. Dealing with these input/output stuff under windows gave my quite some headache as I had to rely on some functions I never heard of and the program still showed some odd behaviour.

Roman

Hi
You can for sure get some odd behaviour with threads also!
The standard problems are:

- The program wont accept input any more. This is because the INPUT_CONSUMED event wasn't set after a command is handled.
- Some input was missing. This is probably because two INPUT_CONSUMED event was set with only one command handled.

It's mentioned in the readme file
/Peter

Roman Hartmann wrote:Guess I will put that on my todo list then as I have some other things to fix as well and diving into Posix stuff doesn't sound like a lot of fun to me

Roman

Hi Roman,
there is a free C++ input library on my site (WWW button below) that can handle input with threads on Windows and POSIX systems (tested on Linux and Mac OS X so far), as well as polling (Windows only, it's not needed elsewhere).

Hi Peter, Hi Alessandro,
thank you both for your help. I had a look at the template Peter offered but didn't impelement it yet. Looks like a nice and clean solution to me though. Also took some books from the shelf to see what they offer on this topic. I'm a newbie if it comes to threads. Anyway, it make sense to me to have a separate thread to deal with input. Maybe I will rather use _beginthread() than ThreadFunc(). Seems to be a bit simpler, at least at first sight.

But I need to have a closer look at it again as I also want to port the engine to Linux without too much changes on the code. So I definitely will have a look at Allesandros library before I'm going to make any changes.

Again, thanks a lot!
Roman

I was close to rewrite big parts of my input/output handling just to be able to use a 2nd thread to deal with inputs. But before trying that I commented all my setbuf(stdout, NULL) out and put a fflush(stdout) after all relevant printf() statements. I remember Vincent even wrote in another thread that would be the better choice anyway.
What can I say, it seems to work under F8 at least. In fact the engine seems to respond much smoother now. The engine was often hanging when running WAC under the F8 GUI if some other app. used some cpu power and I had to kill the engine with the taskmanager.
Still I will probably add a 2nd thread in the future to deal with all the input stuff. I guess instead of passing strings from thread to thread I will create some global variables which whill indicate the state the engine is currently in. I'm more familiar with C than with C++ obviously.

Again thanks for all the help and suggestions!
Roman