[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
|