PH>
  > AFAIK there is/was a little bug (?). DosSleep (0L) won't
  > release a complete timeslice, but DosSleep (1L) will. I'm
  > not very sure about this, but after a few tests, I got very
  > different results from those two calls. You'll have to try,
  > which one fits better for the input loop.
PH>

  DosSleep(0), since it invokes the dispatcher upon return from the
  kernel, yields to any thread with equal or high priority.  It doesn't
  necesarily release a timeslice if no such threads exist.

  DosSleep(1), since it always releases at least one timeslice, will
  yield to lower priority (e.g. idle class) threads as well.

  Yielding time with DosSleep is a Windows-ism, and not the most
  efficient way of multitasking, since it incurs the penalty of two ring
  transitions per call, especially if there are no other threads in the
  ready state that can be yielded to.  Far better to use blocking I/O,
  and let the normal scheduling mechanisms control thread dispatching.

PH>
  > When measuring 64 Threads usind DosSleep(1L), the CPU load
  > raises to 17%. When doing the same with DosSleep(0L) to
  > "pre-empt" the current thread voluntarily, the CPU load
  > raises to 100%.
PH>

  A good example.  DosSleep(0) was doing all that work with ring
  transitions and stuff, but not actually yielding any time (Pulse uses
  idle class threads to measure CPU load, which wouldn't be yielded to
  by regular class threads with DosSleep(0)).

  So your threads were spending time calling DosSleep(0) in a tight
  loop, and effectively being CPU-bound in a busy wait loop (which is
  bad), most of which loop was *in the kernel* (which is worse).

  > JdeBP <
___
 X MegaMail 2.10 #0:

--- Maximus/2 2.01wb