SharedQueue>>peek behavior?

Stephen Pair stephen at pairhome.net
Mon Jul 14 16:03:19 UTC 2003


Ned Konz wrote:

>On Monday 14 July 2003 08:06 am, goran.krampe at bluefish.se wrote:
>
>  
>
>>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.
>>    
>>
>
>Merge it in what way?
>
>  
>
>>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.
>>    
>>
>
>So how would I make a SBS equivalent to a SharedQueue?
>
>Would that be something like:
>
>(SharedBufferStream on: (Array new: 10)) setBuffered: true; yourself
>
>I did that, and noticed that:
>
>* flush on a non-empty queue didn't cause next to block properly:
>
>testFlushNonEmpty
>	"This is one of Nathanael's examples from his email"
>	p1 _ [ q nextPut: 100.
>			q flush.
>			q next. ] fork.
>	self assertWaitingOnQ: p1.
>

If you want equivalence to SharedQueue, you should #setBuffered: to 
false.  The semantics of flush in SharedBufferStream and SharedQueue are 
quite different.  In SharedQueue, flush throws out the contents of the 
queue (effectively consuming all pending items).  However, in 
SharedBufferStream, flush is similar to other buffered write streams in 
that flush indicates that all pending writes should actually be written 
(ie. made available to any readers).  Therefore, it is correct that a 
#next following a #flush would not block when there are objects in the 
stream.  If want to clear the contents of a SharedBufferStream, you'd 
use something like "sbs next: sbs size"...try the following test (

testSBSFlushNonEmpty
	"This is one of Nathanael's examples from his email"
	p1 _ 
		[ sbs nextPut: 100.
		sbs next: q size.  "clear the contents of the stream"
		sbs next. ] fork.
	self assertWaitingOnSBS: p1.



>* peek on an empty queue behaves like a SharedQueue (i.e. it doesn't 
>block if there's no data available), but has a more accurate method 
>comment.
>

Perhaps we should have two methods: #peek (blocking) and #peekOrNil 
(non-blocking)

>* #nextOrNilSuchThat: and #flushAllSuchThat: don't exist
>  
>

These should be easy to add and could likely be made faster than the 
SharedQueue implementation if you use the collection copying/replacement 
primitives.  I would rename #flushAllSuchThat: to #consumeAllSuchThat: 
(and maybe add a #consumeAll method to do what SharedQueue>>flush does).

- Stephen




More information about the Squeak-dev mailing list