On Monday, 16 November 1998,
     MIKE RUSKAI wrote to IVAN TODOROSKI about PM drawing priorities...

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

 MR> Can't meet your test conditions here, as far as I can see.

      It's very hard to reproduce this on fast machines...

 IT>> communications programs, networking daemons etc. PM operations
 IT>> have ABSOLUTELY NO PLACE running at priority higher than 0x41F
 IT>> (Foreground Server, level 31) the way they do now, since they are
 IT>> very rude in regards to releasing CPU cycles voluntarily.

 MR> How did you reach this conclusion?  All it would take to meet the
 MR> conditions you lay out is normal priority with one delta higher, and a
 MR> constantly ready-to-run thread.

  I reached this conclusion by simply running a process at Server
  priority, delta 31 and watching it freeze when I dragged some windows
  around.

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

 MR> Have you tried PRIORITY=ABSOLUTE, to see how it affects the test?

  Yes, no change... detailed explanation is in my previous messages.

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

 MR> As far as I know, this is precisely how it works.

  Well, it works that way NOW, after I patched the kernel, otherwise it
  doesn't.

      Thanks for your reply.

                                                            - Ivan -

.!. Dear Santa, all I want is your list of naughty girls.
--- Terminate 5.00/Pro [OS/2]
 þ TerMail/QWK þ