[concurrency-interest] Why no blocking peek call for j.u.c.BQ?

Paul Phillips paulp at improving.org
Wed Jun 17 19:36:42 EDT 2009


On Wed, Jun 17, 2009 at 03:51:42PM -0700, Taylor Gautier wrote:
> After asking this question, I read this bug report, 
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6653412
> 
> Where I think I agree with the reviewers comments - is there a real 
> use case?

I certainly noticed the absence of that method when writing this:

http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk/src/library/scala/xml/pull/XMLEventReader.scala

It is an XML pull parser.  It presents an iterator interface to the 
user, but because the underlying data may be coming from an arbitrary 
stream which may be arbitrarily slow, we need a way to distinguish end 
of stream (hasNext returns false) from an empty queue (where hasNext 
needs to block, since it doesn't know if there is will be a next.) So we 
insert a poison object when the producer is done producing.

If there is a blocking peek method, I can write it without having to 
manually implement a one element buffer.  hasNext calls peek and returns 
false if it sees the poison object, true if it sees anything else, and 
blocks as long as necessary on an empty queue.  Lacking a blocking peek 
I have to either poll or implement a buffer, neither of which appeals 
compared to the missing alternative.

So unless I missed some way better way to model this (undoubtedly a 
possibility) there's at least one reason.  And there are more in the 
later comments in that bug report.

-- 
Paul Phillips      | A Sunday school is a prison in which children do
Apatheist          | penance for the evil conscience of their parents. 
Empiricist         |     -- H. L. Mencken
slap pi uphill!    |----------* http://www.improving.org/paulp/ *----------


More information about the Concurrency-interest mailing list