WOW!!! My theory presented at the end of my previous message to Jeff
  Dunlop IS correct! After changing the MAXWAIT setting to 2, the
  return times were EXACTLY 2000ms! It proves beyond any doubt that
  background processes at any priority less than 0x300 (Time Critical,
  level 0) run only by means of the starvation boosts when there is
  intensive PM screen I/O... just try it and see for youself.

  One way to produce intensive PM screen I/O is good ol' Netscape 2.02.
  Just load a very long and complex page, and scroll down it by holding
  the down arrow key untill the keyboard starts chirping. But in order
  to reproduce my results, you must make sure there is no background
  disk activity, like flushing of the disk cache or saving the WPS INI
  files, since disk activity apparently tends to force the scheduler to
  perform task switches more often, and ping will show return times
  smaller than 2000ms (they were about 30-200ms in my case).

  This also proves what a marvelous piece of software that OS/2 kernel
  is... I mean, it gave back control to the ping process in EXACTLY
  2000ms, not a millisecond more or less! That is quite an achievment in
  its own right, since it proves that OS/2 is a truly preemptive
  multitasking system, and even the elementary graphics operations are
  not excluded from that preemption, it is just that its capabilities
  are sadly underused by the scheduling policy and the single PM message
  queue in my oppinion... I wonder if anyone can explain the reasons for
  this design?

  I think that much improvement could be achieved by either:

  1) changing the task scheduling policy from HIGHER-PRIORITY-GETS-ALL
     to the more reasonable (in my oppinion) assignment of CPU time
     PROPORTIONAL to the thread priority. This would allow for very
     precise fine tuning of the amount of CPU time each process gets in
     a busy system, and would lead to much smoother multitasking and
     greater performance. The Time Critical class could still be left
     for those rare processes that SIMPLY MUST have control over the CPU
     immediately when they ask for it, and which are known to politely
     release CPU cycles when not needed, such as communications
     programs, networking daemons etc. PM operations have ABSOLUTELY NO
     PLACE running at priority higher than 0x41F (Foreground Server,
     level 31) the way they do now, since they are very rude in regards
     to releasing CPU cycles voluntarily.

  2) Allowing finer control of the MAXWAIT setting, by changing its
     meaning to milliseconds instead of seconds. This would allow the
     user to change the starvation timeout to say 1/10 of a second, or
     even lower, which would be more acceptable and would provide better
     multitasking than the present minimum of 1 second. But this is more
     of a kludge than a solution, because too small values of MAXWAIT
     would lead to CPU saturation when there are many CPU intensive
     background processes competing for CPU time, and would greatly
     detteriorate the response of the foreground application, since the
     CPU would have to serve so many starvation boosts, it would
     hardly have time for anything else. But at least you'll be in
     control of what's happening, and will be able to fine tune the
     setting to your particular situation.

  3) allowing the user to set the priority of PM drawing operations
     (within limits of course), or atleast lowering it

  4) making the priority of PM drawing the same as the priority of the
     process requesting it (this is a variation of the previous
     alternative)

   The options are listed in order of desirability.

  Making OS/2 use multiple asynchronous PM message queues would be nice
  too, but I think that the above improvements are much more important,
  since the single message queue doesn't really hamper system
  performance that much, it just provides for a little less responsive
  GUI.

  Once again, sorry for the long messages, I hope you didn't just skip
  over them :)

                                                            - Ivan -

.!. Shoot your program and put it out of its memory!
--- Terminate 5.00/Pro [OS/2]
 þ TerMail/QWK þ