Boris Gaertner wrote:
> This question relates to Squeak 3.7.
> 
> In the instance method  peek  of  SharedQueue we read
> this:
> 
> "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."
> 
> The last sentence is wrong. What really happens is that peek
> returns immediately with  nil  if no object has  been sent.
> This is clear from the very understandable code, but it can
> also demonstrated with this code snippet:
> 
>  | sq |
>  sq := SharedQueue new.
>  sq peek 
> 
> A quick look through earlier versions of Squeak (back to 2.3)
> reveals that this method has not been changed since Squeak 2.3
> and there is reason to believe that it was in fact never changed.
> 
> SharedQueue>>peek is sent in  EventSensor>>peekEvent.
> 
> 
> I think that the comment of the method is wrong (it was credibly
> simply copied from  SharedQueue>>next) and should be fixed.
> I do not think that the method itself is wrong, but my question is:
> 
> Are there arguments in favour of a peek that suspends the requestor
> until an item is put into a shared queue?

You have noticed interesting flaw in the set of methods which SharedQueue supports. We have two methods which implement "destructive read"
	- next
	- nextOrNil
They are related but the first one is blocking and the second one is non-blocking.

Then we have "non-destructive read"
	- peek
but we have only its non-blocking version. To be consistent, I would suggest renaming this method to
	- peekOrNil
and implement also its blocking version.

For the sake of completeness and consistence. Maybe.

> 
> Your advice will be appreciated.
> 
> Greetings,
> Boris
> 
> 
> 
> 
-- 
 http://altair.dcs.elf.stuba.sk/wiki/Kosik/Main
  icq: 300133844
phone: 0910-993-245