Problem with tight kbhit() loop
Alex Oleynikov
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.
Thanks in advance,
Alex
A. Sinan Unur
news:frN89.72711$Pb.31...@news2.east.cox.net:
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
as...@c-o-r-n-e-l-l.edu
Remove dashes for address
Spam bait: mailto:u...@ftc.gov
Eli Zaretskii
> Newsgroups: comp.os.msdos.djgpp
>
> 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).
Is this on plain DOS or on Windows?
If the former, I think it's a known side-effect of the way CWDPMI
implements the DPMI Interrupt 31 handler: after certain operations
interrupts are left in disabled state. Try inserting __asm__("sti")
inside the loop, and I think the problem will go away.
Alex Oleynikov
"Eli Zaretskii" <el...@is.elta.co.il> wrote in message
news:7263-Thu22Aug200...@is.elta.co.il...
> > From: "Alex Oleynikov" <al...@compuweigh.com>
> > Newsgroups: comp.os.msdos.djgpp
> >
> > 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).
>
> Is this on plain DOS or on Windows?
No, this is plain DOS.
> If the former, I think it's a known side-effect of the way CWDPMI
> implements the DPMI Interrupt 31 handler: after certain operations
> interrupts are left in disabled state. Try inserting __asm__("sti")
> inside the loop, and I think the problem will go away.
Yepp, you are right - this takes care of the problem.
Thanks for your help.
Alex
Alex Oleynikov
"A. Sinan Unur" <as...@c-o-r-n-e-l-l.edu> wrote in message
news:Xns9271C2B62A25...@132.236.56.8...
This fix works.
> so that your environment (probably windows) remains responsive.
No, there is no sight of Windows on that computer - DOS only.
Thanks for advice.
Alex