[squeak-dev] User interrupt does not always break UI process

Bert Freudenberg bert at freudenbergs.de
Fri Jun 24 13:32:21 UTC 2011


On 24.06.2011, at 05:20, David T. Lewis wrote:

> On Thu, Jun 23, 2011 at 04:26:41PM +0200, Bert Freudenberg wrote:
>> I often get the Finalization process when I press Cmd-.
>> 
>> Usually I want the UI process. But it should be possible to break into
>> a higher-level one too, if it takes much time. Not sure if this could
>> be made more intelligent?
> 
> It's a bit of a tricky problem. The interrupt key gets noticed by the
> VM, which signals the FinalizationSemaphore, which gets noticed by the
> finalizationProcess, which needs to figure out what process was the
> likely cause of the user hitting the interrupt key. It's not necessarily
> the UI process, because the problem may have originated from e.g.
> "[Smalltalk createStackOverflow] fork".

I think you mean the InterruptSemaphore, waking up the userInterruptWatcher process.

> To me, the more interesting part of the problem is the fact that the
> finalization process is frequently being selected as the process that
> the user was "probably trying to interrupt". That means that the
> finalization process is consuming so much processor resource that
> it get interrupted instead of the actual process that the user intended
> to interrupt with the Cmd-. key.
> 
> This seems to be typical of images that have accumulated a lot of
> use and that tend to get sluggish over a long period of time. It
> suggests some opportunity to improve the weak finalization process
> overall. This is not a trivial problem by any means, and it has
> been discussed before, but if I'm interpreting this correctly it
> might be better to put some effort into trying to improve this,
> as opposed to trying to make the user interrupt handler be smart
> enough to avoid interrupting the finalizationProcess.
> 
> In terms of near-term improvements that might be possible, perhaps
> it would help to have tools to reduce the amount of cruft that the
> finalizationProcess needs to deal with. Various weak references
> seem to accumulate over time, probably for no good reason, and
> eventually this seems to lead to sluggish images and heavy loads
> on the finalizationProcess.
> 
> - Dave

In my case I don't want it to ever interrupt the higher-priority "system" processes (event tickler, low space watcher, finalizer), but the "last" user process. Not quite sure how to determine that, though. 

Crazy idea: On user interrupt, sample the system for 100 ms to see which process takes up so much time. Too crazy? ;)

- Bert -





More information about the Squeak-dev mailing list