[squeak-dev] The broken user interrupt,
or the saga of 100000 factorial.
Christopher Oliver
current.input.port at gmail.com
Thu Dec 15 01:51:58 UTC 2011
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
|