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