Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: questions about using fget as waiting loop

Author: Uri Blass

Date: 13:09:59 08/30/04

Go up one level in this thread


On August 30, 2004 at 15:39:45, Robert Hyatt wrote:

>On August 30, 2004 at 14:40:25, Uri Blass wrote:
>
>>On August 30, 2004 at 13:57:59, Robert Hyatt wrote:
>>
>>>On August 30, 2004 at 11:25:26, Alessandro Scotti wrote:
>>>
>>>>On August 30, 2004 at 10:20:05, Robert Hyatt wrote:
>>>>
>>>>>What do you do about the case where you type "command"<CR>  "command"<CR> (two
>>>>>commands) before your program does the "check for input"?  You do the first
>>>>>fgets() and the C library sucks both commands into its internal buffer, by
>>>>>reading the data from the O/S, and it gives you the first command.  Now when you
>>>>>ask "is there more input" you are asking the O/S and it says "no" even though
>>>>>the C library has the second command in its buffer.  This is a _common_ problem
>>>>>when people first modify their engines to run with winboard/xboard.  It is such
>>>>>a problem that Tim and I wrote a lot of text to explain why this is a problem
>>>>>and how to get around it...
>>>>
>>>>Well I don't know because I've never found this problem in any of my prototypes.
>>>>Maybe it's the mix of asking both the O/S and the standard lib that messes
>>>>things up.
>>>>I have a separate thread that performs fgets (I also tried fread and ReadFile
>>>>and they work as well) and simply blocks if there is nothing to get. I have just
>>>>tried the experiment you suggested and it works fine, probably because I always
>>>>use fgets() so I'm reading from the same buffer.
>>>
>>>
>>>The problem is that the question "is there input to read" polls the operating
>>>system, not the library buffer.  That's why all the warnings and explanations
>>>are in the engine interface document that comes with xboard/winboard.
>>>
>>>The only solutions are (a) threads;  (b) non-buffered I/O.  Either works.
>>>Threads cause a few more portability issues.
>>
>>I do not use threads and use fget and Movei could play many games with no
>>problem(the only problem is that I cannot check often for getting input during
>>pondering like crafty unless I want to do the program significantly slower).
>>
>>I use input_available function(I post the function later in this message) to
>>find if there is an input during pondering and if there is an input I use fget
>>to get the command and if the command is  time command I wait passively for
>>winboard command by fget.
>>I assume that winboard will send me a move immediately after time command.
>>
>>int input_available(void)
>>{
>>	DWORD nchars;
>>/* When using Standard C input functions, also check if there
>>is anything in the buffer. After a call to such functions,
>>the input waiting in the pipe will be copied to the buffer,
>>and the call to PeekNamedPipe can indicate no input available.
>>Setting stdin to unbuffered was not enough, IIRC */
>>//input_init();
>>	if (stdin->_cnt > 0)
>>		return 1;
>>	if (is_pipe)
>>	{
>>/* When running under a GUI, you will end here. */
>>		if (!PeekNamedPipe(input_handle, NULL, 0, NULL, &nchars, NULL))
>>			return 1;
>>/* Something went wrong. Probably the parent program exited.
>>Could call exit() here. Returning 1 will make the next call
>>to the input function return EOF, where this should be
>>catched then. */
>>		return nchars != 0;
>>	}
>>	else
>>    if (nodes&Nodes_Frequency)
>>		return 0;
>>	else
>>	return _kbhit(); /* In "text-mode" without GUI */
>>}
>
>That will not work reliably.  If you run with winboard/xboard long enough it is
>guaranteed to hang for the reason I gave.

I remember games when it lost on time in the first move in my tests but it
happened rarely and I did not investigate it.
losing on time in most cases that I found was because of different bugs.

  PeekNamedPipe will not see input that
>has already been read by the C library and tucked away in a library buffer.
>
>That is a ticking time-bomb that will cause you to lose on time here and there
>when playing on a server, where you get sent two commands quickly and lose the
>second.

I think that winboard always send the time command and immediatly after it the
move and the question in this case is why usually movei has no problem to get
these 2 commands by 2 fgets after it use PeekNamedPipe to check if there is
input that is available.

Uri



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.