KS> get out of the DIVE sample. The Lotus thing updates the little graph
 KS> about 3-4 times as often as the one in pulse, and the effect is a lot
 KS> more pronounced than with pulse.

Is this lotus application also a cpu monitor?   I didn't realize that. If
so,  it has the right to be soaking up the idle time priorities,  but it
would be better if it had a DosSleep(1) in their spin loop.

 KS> Will do. Incidentally, what's a better way to make a Pulse-type app? I
 KS> mean, the DosSleep() approach doesn't seem to work too well, so what
 KS> would be a better indicator? (IMO, the amount of disk grinding I hear
 KS> while using OS/2 seems like a lot more reliable indicator. :))

The only way to truly know how busy OS/2 is is with the cooperation of the
kernel's scheduler.  I think there may be undocumented api's to enable this
(with added system overhead).   Ask Frank C. (of Pegasus). I think Pegasus
and SPM/2 use them.

Pulse is useful,  as long as you know what it is displaying.  It is NOT
displaying "CPU usage",  or "CPU load".

It IS displaying an upsidedown graph of the amount of idle-class cycles
that are available.  When pulse is at 0%,  all of the idle-class cycles are
being used by pulse (ie: no one else wants them).  When pulse is at 100%, 
pulse is not getting any idle-class cycles;  which could be caused by many
things -- but it does NOT mean that a program at normal (or higher)
priority would not get all of the cycles it wants;  in other words, even if
Pulse is at 100%,  it is _possible_ that a normal priority application
would be unaffected,  and would run at full speed.

As someone mentioned here,  a simple solution would be to write a Pulse for
each priority class -- but this would adversely effect the performance of
the programs that really need the cycles.


--- Maximus/2 2.01