Author: Robert Hyatt
Date: 13:26:16 08/30/04
Go up one level in this thread
On August 30, 2004 at 16:09:59, Uri Blass wrote:
>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
Probably a bit of 'luck'. There's no other explanation.
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.