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

David T. Lewis lewis at mail.msen.com
Fri Dec 16 13:58:23 UTC 2011


Bug tracking notes:

I have added Andreas' note below to Mantis 7656.
  Mantis 7656: User interrupts key does not always work the first time it is pressed.

The parent Mantis issue for several related issues is <http://bugs.squeak.org/view.php?id=7655>
  Mantis 7655: A mother for user interupt bugs and problems

Background on the underlying signaling mechanism (not directly
related to the current discussion but worth knowing) is
  Mantis 1041: [VM][ENH] LowSpaceAndInterruptHandler-dtl

This one is still open but should probably be closed as a "will not fix"
  Mantis 4818: [KernelImageOverride] InputSensor userInterruptWatcher

Dave

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...
> 
> Cheers,
>   - Andreas
> 



More information about the Squeak-dev mailing list