[Bug][Base][WindowManager terminate] -- sets priorty to priority +1 without checking if already highestPriority

WindowManager terminate {initialize-release}

Sets priority to priority +1, which fails if priority is already
highestPriority.

Instead of
        ["baseProcess suspend."
        windows := OrderedCollection new.
        baseProcess ter min: Processor highestPriorityminate] forkAt:
baseProcess priority + 1.

should be
        ["baseProcess suspend."
        windows := OrderedCollection new.
        baseProcess terminate] forkAt: (baseProcess priority + 1 min: Processor
highestPriority)
--
[hidden email]
(503) 627-5890  Desk   (503) 627-1388  Fax

Mark Ballard wrote: [fix snipped]
 >

I've observed this in the past, specifically when breaking View code
that might be used by the debugger (like RBCodeHighlighting).

Typically the forked code above should be running at priority 51, but if
the debugger's View fails the termination algorithm above is called
repeatedly and (the debugger?) ratchets the processor priority up beyond
legal values at which point it raises a notifier.

IMO it is desirable that it blows up this way, with your fix it will
keep spinning at a priority that will keep the image in livelock, no GUI
events will be processed.

My conclusion at the time was:
  don't change this behavior, it ain't broke.


If this occurs some *other* piece of code needs fixing.



Cheers,

Reinout
-------

Reinout,

Thanks.

I'll look and see if I can find the cause in my environment.

-----Original Message-----
From: Reinout Heeck [mailto:[hidden email]]
Sent: Wednesday, July 05, 2006 10:59 PM
To: [hidden email]
Subject: Re: [Bug][Base][WindowManager terminate] -- sets priorty to
priority +1 without checking if already highestPriority


Mark Ballard wrote: [fix snipped]
 >

I've observed this in the past, specifically when breaking View code
that might be used by the debugger (like RBCodeHighlighting).

Typically the forked code above should be running at priority 51, but if

the debugger's View fails the termination algorithm above is called
repeatedly and (the debugger?) ratchets the processor priority up beyond

legal values at which point it raises a notifier.

IMO it is desirable that it blows up this way, with your fix it will
keep spinning at a priority that will keep the image in livelock, no GUI

events will be processed.

My conclusion at the time was:
  don't change this behavior, it ain't broke.


If this occurs some *other* piece of code needs fixing.



Cheers,

Reinout
-------

Mark

As Reinout stated, the real problem is that something else
is broken.

No window manager process should have a priority higher
than (lowIOPriority - 1) and for all practical purposes
only the debugger should use this priority. Other WMs should
be less than (userSchedulingPriority + 10). For terminating
it should be ok for it to be lowIOPriority, because this is
a transient condition, but it should never be higher. This
is because InputState runs at lowIOPriority. If the WM runs
at lowIOPriority or higher it could lock out input events.

Terry
 
===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

Terry Raymond wrote:

So for debugging it might be helpful to put a test in the WM's process
creation method(s) that checks that its priority < lowIOPriority (or
perhaps allows only userSchedulingPriority and lowIOpriority -1) so you
halt closer to the erroneous code.


HTH,

Reinout
-------