[squeak-dev] Re: The broken user interrupt, or the saga of 100000 factorial.

David T. Lewis lewis at mail.msen.com
Thu Dec 22 21:24:17 UTC 2011


On Fri, Dec 16, 2011 at 08:00:03AM +0100, Andreas Raab wrote:
> On 12/16/2011 3:33, Levente Uzonyi wrote:
> >On Thu, 15 Dec 2011, Christopher Oliver wrote:
> >
> >>On Thu, 15 Dec 2011 11:35:55 +0100
> >>I added a tty output debug to
> >>MorphicProject>>interruptName:preemptedProcess:, and I found
> >>that Processor>>preemptedProcess occasionally answers the system weak
> >>array finalization process. Yikes! This isn't what we want to debug at
> >>all. Are we being adequately clever
> >>in determining which process to debug?
> >
> >I'm pretty sure that the currently running process is interrupted. After
> >GC (which happens often during calculations with LargeIntegers) this is
> >likely to be the finalization process.
> 
> Correct. To make matters worse, when an interrupt is signaled in the 
> midst of GC, the signal will be delivered after the GC cycle completes, 
> therefore almost guaranteeing that the interrupted process will be the 
> finalization process.
> 
> And so the determination of the process to be interrupted is moderately 
> stupid. What we'd really need to do is to start a slightly leaner 
> version of CPUWatcher, i.e., instead of blindly interrupting whatever 
> process is active, start sampling the running processes and after a 
> short while (100-500 ms) decide which process to kick[*]. Plus, after 
> that ensure that the UI is actually responsive so that the user can 
> interact with the system and if not, keep kicking processes unless the 
> system becomes interactive again. Alas, not a trivial task to be solved.
> 
> [*] A more radical version would suspend *all* user processes and let 
> the user decide which of the suspended processes to inspect. This might 
> have some interesting side effects though...

I think I found the underlying cause of all this grief, which in fact
has nothing to do with the user interrupt handler. The problem is that
the weak finalization process is very busy due to thrashing between
the VM and the image. The VM notifies the image when weak references
need to be cleaned up, and the weak finalization process responds by
creating new weak references for the VM to clean up, etc etc etc ...

A fix is posted to the inbox in Collections-dtl.466

As Andreas observes, creating a smarter user interrupt handler is not
at all trivial. But creating a smarter weak finalization process is
really easy :) The solution was to move the check for VM support of new
finalization out of the finalization process, and perform the check
once at image startUp time.

With that change in place, the following may all be interrupted in
the expected way:

  "[true] whileTrue"
  "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1"
  "Smalltalk createStackOverflow"
  "[Smalltalk createStackOverflow] forkAt: Processor userSchedulingPriority + 1"

Just for the record, this problem was a whole lot harder to figure out
than it was to explain ;-)

Dave




More information about the Squeak-dev mailing list