Problem with tight kbhit() loop

[Alex Oleynikov]

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.

Thanks in advance,
Alex

[A. Sinan Unur]

"Alex Oleynikov" <al...@compuweigh.com> wrote in
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]

> 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?

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