[squeak-dev] The broken user interrupt,
or the saga of 100000 factorial.
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:
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.
Christopher Oliver <current.input.port at gmail.com>
More information about the Squeak-dev