I'm running into various problems debugging a critical section of
code.  Is there a way around them?  Or should it just work, and I
should look elsewhere for the problem?

First attempt: I used Monitor>>critical: and had the halt outside the
call.  However, even though I tried to use send in the debugger to
step into the block, it took me through it.  I have a foggy
recollection of seeing this behavior before.

Second attempt: self halt inside the block.  With this, the debugger
comes up, but when I try to enter the debugger the best I can do is
getting the debugger to come up.  I'm never able to select a stack
frame; my system uses lots of CPU and then the squeak image becomes
totally unresponsive (though CPU is 0).  Even alt-., though it brings
up a notification window, doesn't let me regain control.

Notes/Caveats: 
_____________
Squeak 3.2, last update 4956, i.e., not at all recent.

Running under Debian GNU/Linux.

Image is pushing 70Mg, and I frequently have to wait extended periods
(15 seconds) while it thinks after I do something.  (Could just be
that I'm swapping: 128Mg physical RAM).

If I had more time, I'd deal with some of those problems, but for now
I'm trying to fix a relatively limited bug.

Monitor, as I recall, was a little something I imported.  I've
attached it, just in case.  It lets the owning process in repeatedly,
but prevents other processes from acting.  Hmm, I wonder if using the
debugger implies I've changed active processes, and so Monitor is
blocking me...

P.S. As I have not been following developments closely for quite a
while, I had a browse to try to catch up.  But I could not find a
clean summary of the changes in the different versions of squeak since
3.2.   Any pointers?

-------------- next part --------------
'From Squeak3.2 of 29 April 2002 [latest update: #4956] on 23 March 2004 at 11:21:06 pm'!
Object subclass: #Monitor
	instanceVariableNames: 'accessLock waitSemaphore owner waiting '
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Kernel-Processes'!
!Monitor commentStamp: '<historical>' prior: 0!
A monitor is - like a semaphore - used to synchronize access. Contrary to semaphores, monitors can be entered multiple times by the same process.!


!Monitor methodsFor: 'control' stamp: 'ar 2/3/2002 18:05'!
critical: aBlock
	"Evaluate the given block, excluding accesses from other processes."
	self enter ifTrue:[^aBlock value].
	^[aBlock value] ensure:[self leave].! !

!Monitor methodsFor: 'control' stamp: 'ar 2/3/2002 18:05'!
critical: aBlock ifOwned: ownerBlock
	"Evaluate aBlock if the receiver is not owned by the current process. Evaluate ownerBlock if it is already owned by the current process."
	self enter ifTrue:[^ownerBlock value].
	^[aBlock value] ensure:[self leave].! !

!Monitor methodsFor: 'control' stamp: 'ar 2/3/2002 18:06'!
enter
	"Enter the monitor. Return true if the receiver was owned by the active process, false otherwise."
	| doWait process wasOwned |
	[doWait _ false.
	accessLock critical:[
		process _ Processor activeProcess.
		wasOwned _ process == owner.
		owner 
			ifNil:[owner _ process]
			ifNotNil:[doWait _ wasOwned not].
		waiting _ waiting + 1.
	].
	doWait] whileTrue:[waitSemaphore wait].
	^wasOwned! !

!Monitor methodsFor: 'control' stamp: 'ar 2/3/2002 18:01'!
leave
	"Leave the monitor"
	| process wasOwned |
	accessLock critical:[
		process _ Processor activeProcess.
		wasOwned _ owner == process.
		wasOwned ifTrue:[
			owner _ nil.
			waiting > 0 ifTrue:[
				waiting _ waiting - 1.
				waitSemaphore signal]]].
	wasOwned ifFalse:[^self error:'Process did not own monitor']! !


!Monitor methodsFor: 'initialize' stamp: 'ar 2/3/2002 17:56'!
initialize
	accessLock _ Semaphore forMutualExclusion.
	waitSemaphore _ Semaphore new.
	owner _ nil.
	waiting _ 0.! !

"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!

Monitor class
	instanceVariableNames: ''!

!Monitor class methodsFor: 'instance creation' stamp: 'ar 2/3/2002 18:03'!
new
	^super new initialize! !