On Monday 14 July 2003 12:23 pm, Stephane Ducasse wrote:
> Ned have you looked at the fix that Nathanael sent around at least
> one year ago and that I
> resent recently?

Yes. That's why I was writing the tests.

> 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

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE