From: michael DOT mauch AT gmx DOT de (Michael Mauch)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: RHIDE -- author(s) please read this
Date: Wed, 12 Nov 1997 02:00:02 +0100
Organization: Gerhard-Mercator-Universitaet -GH- Duisburg
Lines: 101
Message-ID: <3469d3af.4126448@news.uni-duisburg.de>
References: <Pine DOT LNX DOT 3 DOT 95 DOT 971111112405 DOT 1351B-100000 AT posaune DOT hrz DOT tu-chemnitz DOT de>
NNTP-Posting-Host: ppp96.uni-duisburg.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

On Tue, 11 Nov 1997 10:31:16 GMT, Robert Hoehne <robert DOT hoehne AT gmx DOT net>
wrote:

> In version 1.4 this should be fixed (at least under Linux I get
> a CPU usage when RHIDE is idle of about 0.8%).

I guess Linux releases timeslices itsself if you continiously poll the
keyboard, but the DOS version of RHIDE doesn't, because it uses kbhit().


DJGPP's kbhit() looks just at the keyboard buffer variables in DOS
memory - that's a fast method, but it doesn't allow multitaskers to
recognize that a program polls the keyboard most of its time.
 
> BTW: If you are running under Windows (what I'm guessing), How do you
> mess the CPU usage? Are you sure, that the shown value is correct?

I use WinTop from Microsoft's Kernel Toys. It shows CPU usage of each
running program. I don't know how accurate the values are, but if I have
RHIDE (1.4) in a foreground window, WinTop even can't repaint it's
window every second, so the 92% CPU usage shown for RHIDE seem rather
reasonable.
 
> And a last note: Have you ever tried, that the __dpmi_yield()
> has any effect? When I remember correct, I tried it already several
> times and couldn't see any effect.

Maybe you can check again with the following little test program(s).

// yield.c
#include <stdio.h>
#include <conio.h>
#include <time.h>
#include <dpmi.h>

void Count()
{
  unsigned long long i;
  clock_t t0, t;

  for(i=0, t0=clock(), t=t0+10*CLOCKS_PER_SEC; clock()<t; i++)
    printf("%llu\n",i);
}

void TestYield()
{
 while(!kbhit())
   __dpmi_yield();
}

int main(int argc,char* argv[])
{
  int Done = 0;

  if(argc>1 && '-'==*argv[1])
    switch(argv[1][1])
    {
      case 'y':  while(!kbhit())
                   __dpmi_yield();
                 Done = 1;
                 break;

      case 'c':  Count();
                 Done = 1;
                 break;
    }

  if(!Done)
    while(!kbhit())
      ;
  while(kbhit())
    getch();
  return 0;
}
// End of yield.c

`yield´ without arguments just runs a kbhit()-loop without yielding,
`yield -y´ uses __dpmi_yield().
`yield -c´ counts for ten seconds and prints the counter to stdout.

The effect of __dpmi_yield() can be seen best if the keyboard polling
program sits in the foreground. Try the following batch file without
arguments and with the parameter `-y´:

:: yield_t.bat
start /m yield -c
yield %1
:: End of yield_t.bat

Make sure that the "Close on exit" checkbox of the `yield -c´ process is
not check, so you can look at its output after it has exited.

On my machine, the `yield -c´ process in the background counts to about
5000 if the foreground process uses plain kbhit(), but to 20000 if the
foreground process uses __dpmi_yield().

So I think using __dpmi_yield() in RHIDE would be a Good Thing (maybe as
an option).

Regards...
	Michael