From: "A. Sinan Unur" Newsgroups: comp.os.msdos.djgpp Subject: Re: Problem with tight kbhit() loop Date: 21 Aug 2002 23:08:28 GMT Organization: Cornell University Lines: 44 Sender: asu1 AT cornell DOT invalid (on pool-141-149-209-18.syr.east.verizon.net) Message-ID: References: NNTP-Posting-Host: pool-141-149-209-18.syr.east.verizon.net X-Trace: news01.cit.cornell.edu 1029971308 8929 141.149.209.18 (21 Aug 2002 23:08:28 GMT) X-Complaints-To: usenet AT news01 DOT cit DOT cornell DOT edu NNTP-Posting-Date: 21 Aug 2002 23:08:28 GMT User-Agent: Xnews/5.04.25 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "Alex Oleynikov" wrote in news:frN89.72711$Pb DOT 3104967 AT news2 DOT east DOT cox DOT net: > Hi all, > > I have a question about using kbhit() function in a tight loop like > the one below: > ... > while( !kbhit() ); > > ch = getch(); > ... > > If I just run the program that contains this code everything works > fine. Now, if I run this program under the RHIDE's debugger and have > some breakpoints prior to the code listed above, then this loop never > quits and computer locks up completely (only cold re-boot helps to > restart it) and sometimes even my CMOS settings are get screwed up, so > BIOS loads their default values at start-up making me go nuts > restoring them :o). > > The problem goes away if I put some time-consuming operation inside > the loop, like a call to printf(..) or delay(..) functions. > > Is there a rational explanation to this situation? Is it specific to > DJGPP? I have tried the same code under Borland Turbo C++ 2.0 and it > always works fine even if I have the breakpoints to visit before > getting into that loop. there is a possiblity that your code contains a bug. however, it is a good idea to modify your loop to while(!kbhit()) dpmi_yield(); so that your environment (probably windows) remains responsive. Sinan. -- A. Sinan Unur asu1 AT c-o-r-n-e-l-l DOT edu Remove dashes for address Spam bait: mailto:uce AT ftc DOT gov