Ned have you looked at the fix that Nathanael sent around at least one 
year ago and that I
resent recently? Because this would be good to have a clean and good 
solution.
I'm bad at concurrency and I would to really on good abstraction. I 
think that
having good examples to learn from is key.

Stef

On Sunday, July 13, 2003, at 08:27 PM, Ned Konz wrote:

> Hi folks,
>
> I've just written a set of SharedQueue tests (as well as adding some
> more SharedQueue fixes and a SharedQueue based on Monitor), and
> noticed that the behavior of SharedQueue>>peek is not as documented.
> That is, if the queue is empty, the peeking process does not in fact
> block.
>
> However, the comment says:
> 	
> "Answer the object that was sent through the receiver first and has
> not yet been received by anyone but do not remove it from the
> receiver. If no object has been sent, suspend the requesting process
> until one is."
>
> My new queue does this.
>
> Which behavior do we want? GNU Smalltalk actually (says it) blocks. I
> don't remember what VW does.
>
> Also, I've added a #critical: method on my new queue so that you can
> do things like:
>
> queue critical: [ queue size < highWater ifTrue: [ queue nextPut:
> something ]].
>
> -- 
> Ned Konz
> http://bike-nomad.com
> GPG key ID: BEEA7EFE
>
>