SharedQueue>>peek behavior?

Ned Konz ned at bike-nomad.com
Mon Jul 14 15:25:02 UTC 2003


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.

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

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

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



More information about the Squeak-dev mailing list