BJ> Looks like the BBS is using about half the cpu time 
 BJ> on this system when max is running in console mode. 
 WG>  
 WG> You're right that this has to do with the way the 
 WG> keyboard is being polled: scott does this *often*; I 
 WG> don't know why he didn't hook a keyboard interrupt 
 WG> vector (or, if he did, how missed that usage. ;)

Probably becase the code hooks another interupt to allow sharing CPU time
with other programs, and is probably called every time in the loop sometime
after the keyboard is check.....  And this varied depending on which
multi-tasker was in use.....  That's why there are key words for Desqview,
OS/2 and some others.

 WG> It's not that expensive under my system, but this may 
 WG> have to do with how your version of curses implements 
 WG> non-blocking reads.

Ah, yes....

 WG> One way to reduce the amount of CPU use is to use a 
 WG> short blocking read (see the timeout() functionalityin 
 WG> the curses library). Unfortunately, this has had some 
 WG> other side effects (like a screen running one char 
 WG> behind) due to (what I think) is a bug in curses. 

I've seen this one character issue / bug in other software.  I think it
gets back to how the C compiler libraries handle pointers on character
devices..... 
 WG> I'm tempted to implement a separate thread which does 
 WG> some kind of exponential-backoff poll on the keyboard, 
 WG> and provides the input back to the kgetch() routines in fos_os2.c(?). 

Instead, find where Scott hooked the interupt used for calling the
multi-tasker's wait state....  And put something in there.....

 WG> Hmm. This may need some more thought; I'll post back 
 WG> when I have more ideas. Or if you have some, that'd be 
 WG> cool. :)


Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01