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
|