Hi all!

Perhaps Ned you could "merge" your work with the SharedStreams package?
Tests should work for both and any other bugs or pecularities found
could be fixed in SharedStreams too.

Another thing with SharedStreams is that they should be much faster for
many objects. I did compare them for characters and the difference was
huge.

regards, Göran

Stephen Pair <stephen at pairhome.net> wrote:
> 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 ]].
> >  
> >