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

Martin Buchholz martinrb at google.com
Sun Jun 28 14:53:00 EDT 2009


A belated followup.

I was the Sun engineer who supplied the evaluation for
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6653412

I agree with Dimitris that having to keep track of the "next" item
is a little annoying, but not so annoying that we should change the API.
Many of the iterators in j.u.c. cache the next item so that hasNext()
return of true does not become a lie.

Martin

On Thu, Jun 18, 2009 at 23:48, Jim Andreou <jim.andreou at gmail.com> wrote:

> I don't see this as a compelling use case, which can be summarized: "in
> cases where there is only a single consumer, I could use a blocking peek
> instead of having a variable". Use a variable already. :) The easiness of
> this outweights the cost of having another method (somewhere...), which
> people could call, creating race conditions (as mentioned) when someone
> decides at some time that "perhaps it would be a good idea to add more
> consumers for this queue".
> Regards,
>
> Dimitris
>
> 2009/6/18 Paul Phillips <paulp at improving.org>
>
> 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/*----------
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090628/421b1786/attachment-0001.html>


More information about the Concurrency-interest mailing list