[squeak-dev] The broken user interrupt,
or the saga of 100000 factorial.
Casey Ransberger
casey.obrien.r at gmail.com
Thu Dec 15 07:04:34 UTC 2011
At a glance, the below is some damned fine sleuthing. Excellent work.
On Dec 14, 2011, at 5:51 PM, Christopher Oliver <current.input.port at gmail.com> wrote:
> I spent a bit of time working backwards from the user interrupt watcher process:
>
> InputSensor>>userInterruptWatcher
> SmalltalkImage>>handleUserInterrupt
> MorphicProject>>interruptName:
> MorphicProject>>interruptName:preemptedProcess:
> Debugger class>>openInterrupt:onProcess:
> SmalltalkImage>>logSqueakError:inContext:
> SmalltalkImage>>logError:inContext:to:
> ContextPart>>errorReportOn:
> MethodContext>>printDetails:
> ContextPart>>tempsAndValuesLimitedTo:indent:
> Object>>printStringLimitedTo:
>
> The story runs as follows: you're more than likely to interrupt '100000 factorial' in SmallInteger>>* since that's the bulk of the computation, and the argument aNumber is
> more than likely a LargePositiveInteger. When ContextPart>>errorReportOn: displays
> this, the bignum is converted to a decimal string and then truncated, and this appears
> to be the source of the delay. Nothing prior to or following the invocation of
> Object>>printStringLimitedTo: takes much time at all. This suggests that vars in the
> first twenty frames (see ContextPart>>errorReportOn:) that have a string representation
> that's expensive to compute will make Smalltalk appear to hang on cmd-. I can appreciate
> value in being able to look at the stack dump in SqueakDebug.log to determine where
> Smalltalk was when you hit the interrupt key, so I'm at a loss how is best to go here.
>
> Thoughts?
>
> --
> Christopher Oliver <current.input.port at gmail.com>
>
More information about the Squeak-dev
mailing list
|