Author: Scott Gasch
Date: 17:08:08 04/09/02
Go up one level in this thread
On April 09, 2002 at 13:19:22, Frank Phillips wrote: >First of all thanks to everyone who responded. > >On the thread stuff, I have tried an approach similar the code below, but never >it got it work properly with therest of my approach to input. > >(Scott) are you saying you do not bother with the cond_wait statement and just >increment a buffer counter for items of input to be parsed, so effectively the >thread is always stuffing available input into the buffer? I guess you lock the >buffer during reads? It would mean a redesign of the input and parsing >routines, but is attractively clean and, as you say, lets you deal with some >input without bothering the search. > Yeah the input thread is always blocked waiting on input. It's life is just to loop trying to read and, when it reads a line, see if it can reply right away and, if not, stuff it on a queue for the main thread to look at when it gets around to it. The count of things on the queue is maintained and the queue is locked when it needs to be... adding to it or deleting from it. So, the input thread can respond to some things instantly. The main thread can "peek" at the next input without doing any sort of I/O library tricks. And the main thread can choose to read (i.e. dequeue) an input chunk anytime it wants to. Instead of select() or GetNumConsoleInputEvents() I just test: if (pInputQueue->iNumInputs != 0) ... then input is waiting. It's not such a big redesign as you might think, maybe. The only changes I made were to my IsInputWaiting() function and then to remove all calls to fgets() and replace them with either PeekQueue() or ReadQueue(). It may or may not work out well for you but I was pretty happy with the results... and it's pretty portable I think. Good luck! Scott
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.