SharedQueue>>peek behavior?
Stephen Pair
stephen at pairhome.net
Mon Jul 14 14:37:50 UTC 2003
Ned Konz wrote:
>On Monday 14 July 2003 06:15 am, Stephen Pair 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).
>>
>>
>
>I just took a look at it. It looks nice, but it also suffers from the
>same problem that SharedQueue does: that is, it's impossible to use
>the tests like #isEmpty, #size, #ensureAvailable:, #isClosed,
>#isClosedForReaders, etc. reliably.
>
>As Scott Crosby pointed out last year, you really want to be able to
>do something like:
>
>q critical: [ q isEmpty ifFalse: [ "do stuff" ... q next ]]
>
>and be able to trust that the size will remain constant within the
>wrapped block.
>
Do you have a reference to that email? I'd like to see what kinds of
things require such usage.
>I was able to do this easily with my MSharedQueue using a Monitor.
>Perhaps a version of SharedBufferStream could be made that used
>Monitor and would allow this kind of usage?
>
I'm sure these problems can be ironed out but these problems aren't
really what I'm most concerned about (they can be corrected)...what
bothers me about SharedQueue is that even though it is a stream like
thing, it isn't implemented to support a stream like protocol (including
being closed). It's infinitely more useful if it does support a stream
protocol (for instance, a pair of SharedBufferStreams can be used as a
drop in replacement for a SocketStream (as SharedBidirectionalStream
does), or a single SharedBufferStream can be used to substitute for an
OS pipe...additionally, services can be made very clean if they only
assume that they pull event objects off of a stream...and a
SharedBufferStream is very handy thing for sending events to some service).
- Stephen
More information about the Squeak-dev
mailing list
|