Hi folks,

I've just written a set of SharedQueue tests (as well as adding some 
more SharedQueue fixes and a SharedQueue based on Monitor), and 
noticed that the behavior of SharedQueue>>peek is not as documented. 
That is, if the queue is empty, the peeking process does not in fact 
block.

However, the comment says:
	
"Answer the object that was sent through the receiver first and has 
not yet been received by anyone but do not remove it from the 
receiver. If no object has been sent, suspend the requesting process 
until one is."

My new queue does this.

Which behavior do we want? GNU Smalltalk actually (says it) blocks. I 
don't remember what VW does.

Also, I've added a #critical: method on my new queue so that you can 
do things like:

queue critical: [ queue size < highWater ifTrue: [ queue nextPut: 
something ]].

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE