Once again, I'd like to lobby for the destruction of SharedQueue in 
favor of Goran's Shared Streams package.  With a SharedBufferStream, you 
get everything you need from SharedQueue, but it uses the more standard 
stream protocols, and it has the ability to be closed (so you can have a 
process that loops on an #atEnd test).

- Stephen

Ned Konz wrote:

>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 ]].
>  
>