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

David T. Lewis lewis at mail.msen.com
Fri Dec 16 02:31:05 UTC 2011


On Thu, Dec 15, 2011 at 08:06:19PM -0500, Christopher Oliver wrote:
> On Thu, 15 Dec 2011 11:35:55 +0100
> Bert Freudenberg <bert at freudenbergs.de> wrote:
> 
> > Sounds tempting, but I don't think that is the core of the problem. Try this in Debugger>>openInterrupt:onProcess:
> 
> I'll look at these, but figure I'd share things found out so far.  I've been using this
> crude instrument to see where and when things are going on:

This is a good way to debug thing like this. FYI, a similar convenience method
is OSProcess class>>trace: if you happen to have OSProcess loaded.

> 
> |counter enabled|
> 
> counter := 0.
> enabled := false.
> 
> WriteTTYEnabled := [:arg| enabled := arg].
> 
> 
> WriteTTY :=
> 	[:arg | | sender |
> 		sender := thisContext sender.
> 		enabled ifTrue:	[
> 			FileStream fileNamed: '/dev/tty' do:
> 				[:handle|
> 					handle 	nextPutAll: '== ',
> 						counter asString,' ',
> 						sender receiver className,'(',
> 						sender methodClass asString,')>>',
> 						(sender method selector)
> 							asString,  
> 						' ',Time now asString,' ==  ',
> 						arg asString;
> 					 lf].
> 			counter := counter+1]].
> 		
> WriteTTYReset := [counter := 0].
> 
> "
> WriteTTYReset value
> WriteTTYEnabled value: true
> WriteTTYEnabled value: false
> "
> 
> When I file this in and evaluate 'WriteTTYEnabled value: true', I can sprinkle the code I want to understand with 'WriteTTY value: SOMESTRING', and have output on the console without
> depending on morphic display updates and the like.  I put this in the vars loop in ContextPart>>errorReportOn:, and in Object>>printStringLimitedTo: contingent on a Flag in
> the Smalltalk globals.  I found that sometimes, Smaltalk indeed gets stuck converting that
> bignum, but other times, the seems to go astray and the factorial marches on.  Hitting the
> interrupt a second time sometimes succeeds, and two debugs appear after a while: the
> expected factorial, but also BlockClosure>>newProcess/WeakArray class>>restartFinalizationProcess.  This suggests the running process has been misidentified, but I've not much idea what is happening here.
> 
> Thoughts?

I think what you are seeing here is that the finalization process *is*
the running process. It just happens to be the process that is running
at the time the interrupt key event is delivered to the image. I think
I recall Bert suggesting in an earlier thread (months ago?) that certain
normal background processes be excluded from interruption. This might
very well be the best way to handle the issue, but I don't think that
any of us followed up on that suggestion.

If the above is true, then it also begs the question of why the finalization
process should be so active that it just happens to be the process that
gets interrupted so often. That suggests that the finalization process
may be much busier than it needs to be.

Dave




More information about the Squeak-dev mailing list