Hi Andreas!

I think this [1] is the root of the thread. I did test this fix in [2]
by looking at the symptoms and if they would vanish and just came to the
conclusion, that the fix had no positive effect on windows. I did not
look deeper into the problem, but was hoping to sound vague enough with
my analysis of the problem to be instantly corrected by any expert of
the domain! :)

Beers,
	Alex

[1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-May/078325.html
[2]http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-July/079486.html
Andreas Raab schrieb:
> Hi Folks -
> 
> Trying to track a problem in Tweak I ran into the above mentioned
> update. I won't comment on the process of how it got into the image (I
> think you all know my opinion about eyeballing system-critical changes
> and I am almost certain that the approval went something like "oh, what
> possible harm could a one-line change do") but I am rather interested in
> what problem this is trying to fix.
> 
> The comment of the change set states: "The low space watcher is
> interrupted in the context of the wrong process when the eventTickler
> process (or other high priority process) is running. This prevents low
> space detection from functioning properly."
> 
> But this makes no sense whatsoever. The low space watcher can be only be
> interrupted if it is running (non-running processes are never
> interrupted) but all the running low space watcher does is to throw up
> an interrupt (which we all agree on is the right thing to do) on the
> currently active process. If the user presses Alt-period when this
> happens why would it be wrong to interrupt the low space watcher?
> 
> It is precisely the right thing to do (in fact, it is the only thing
> that can be done if we are to honor the user interrupt). If we choose to
> *ignore* the actual running process (such as is done in the above
> update) and just arbitrarily interrupt the "main" project process we
> will never be able to interrupt any run-away process which is different
> from the main process. As an example, take:
> 
>     [[true] whileTrue:[]]]
>         forkAt: Processor userSchedulingPriority+1.
> 
> With the original version of the method you *were* able to interrupt
> that process (try it - revert to its previous version run the above and
> hit alt-period). With the version of the method in the update you will
> not be able to interrupt a runaway process like the above.
> 
> Whatever this update is trying to address, it cannot possibly be what is
> being claimed in the preamble. So what problem is this update trying to
> solve?
> 
> Cheers,
>   - Andreas
>