"Raab, Andreas" wrote:
> 
> Doug,
> 
> > Actually, this situation is very easy to reproduce.  Just
> > execute the following (if you don't mind your image being hosed):
> >
> > [[true] whileTrue: [10 factorial]] forkAt: 5.
> >
> > It would be nice if there were some way to save yourself in
> > this situation.
> 
> Well, the first thing to do is not to run your process at or above
> userInterruptPriority (which is 5) if you want to be able to interrupt it
> via Alt-.

Oops, I guess there's a reason it's called "userInterruptPriority".  So, I suppose that depending on the user interrupt (alt-.) to save oneself from this example doesn't make a lot of sense.

Still, I've seen the problem that Sven described on a few (fairly rare) occasions, and I wasn't forking any higher level processes at the time that I was aware of.  I guess something fairly fundamental must be broken when this happens... it must be a process at userInterruptPriority in an infinite loop.

> The next thing to keep in mind is that even the interrupt process
> does NOT know what process was running before - there is an educated guess
> about it along the lines of "Hm ... user interrupted something ... let's
> show her the UI process because most like that's what she's interested
> in..." but effectively there's nothing the interrupt process knows for sure.

Right, I did figure out that much. :)

> > I haven't dealt enough with Processes to
> > know what the best solution would be.  There might be a way
> > for Squeak to interrupt a runaway high priority process when
> > alt-. is pressed... perhaps if alt-. were pressed, it could
> > check to see if "nothing" was happening in the UI process,
> > and then interrupt remaining higher priority processes (that
> > weren't any of the standard high priority system processes).
> 
> Sorry but what you're describing is impossible. No process at lower priority
> can preempt a process at higher priority unless that process is giving up
> control by itself. Even when you press the interrupt key the only thing that
> happens is that the user interrupt semaphore is signaled which makes the
> user interrupt watcher "runnable". But if there's a higher priority process
> which simply won't go away the interrupt process won't be scheduled.

True.  But for this situation (an infinite loop at userInterruptPriority), something could probably be made to work... maybe. :)  In this situation alt-. does break through occasionally to bring up a pre-debug window.  When it breaks through, it could look for other processes at userInterruptPriority to interrupt first, and if it doesn't find any, then go ahead and interrupt the UI process.  Okay, perhaps this wouldn't be a good idea to add to the base image, but it might be a handy debugging goodie for figuring out what's going on in this type of situation.

> ...
> > The Process Browser doesn't show what percent CPU a process
> > is using, though... that would be cool.  I wonder if it would
> > be possible to implement this via some sort of sampling, kind
> > of like what MessageTally does?  (Although I guess
> > MessageTally only has to worry about one process?)  Even if
> > it worked, it would probably need to be an optional feature,
> > kind of like the auto-update feature in the Process Browser.
> > ...
>
> It could be done if you're willing to pay the price. The VM could measure
> the time some process is running when it switches between processes. But
> these switches may occur frequently (not under "normal" circumstances but it
> it's quite possible) and measuring takes time too (in particular if your
> accurate msecs clock costs you more than a few micro seconds such as on
> MacOS<X).

Or maybe a quicker (no doubt uglier) hack for the Process Browser would be to optionally turn on CPU metering, which would be a special high priority (6 or 7?) process which would sample all lower level processes and report usage. (?)  This would probably kill performance, but might be an interesting debugging tool to turn on temporarily when needed.

- Doug Way
  dway at riskmetrics.com