[concurrency-interest] Why no blocking peek call for j.u.c.BQ?
alarmnummer at gmail.com
Wed Jun 17 18:59:06 EDT 2009
Since you are experienced with instrumentation, you can always enhance
the bytecode so that the notEmpty condition of the LinkedBlockingQueue
gets exposed. This way it is easy to add the desired listen
functionality. Be careful that no signals are eaten :)
On Thu, Jun 18, 2009 at 12:51 AM, Taylor
Gautier<tgautier at terracottatech.com> wrote:
> I think the issue I am thinking of is that there is no way to make a
> blocking call to be notified when the queue is non-empty, yet take no action
> - all of the blocking actions also atomically change the queue contents.
> After asking this question, I read this bug report,
> Where I think I agree with the reviewers comments - is there a real use
> I am asking because someone is asking us (Terracotta) if there is a way to
> do a blocking peek on a Terracotta(ized) LinkedBlockingQueue.
> I've pushed back on the the original poster why they need this
> ----- Original Message -----
> From: "Peter Veentjer" <alarmnummer at gmail.com>
> To: "Taylor Gautier" <tgautier at terracottatech.com>
> Cc: concurrency-interest at cs.oswego.edu
> Sent: Wednesday, June 17, 2009 3:41:06 PM GMT -08:00 US/Canada Pacific
> Subject: Re: [concurrency-interest] Why no blocking peek call for j.u.c.BQ?
> To idea behind the peek is that it should not block unlike a take.
> If you want a non blocking version, you can use the poll(long time,
> TimeUnit unit) method. But it is strange that there is no (non
> blocking) peek method. Perhaps that is the question you wanted to ask?
> On Thu, Jun 18, 2009 at 12:27 AM, Taylor
> Gautier<tgautier at terracottatech.com> wrote:
>> Just wondering why there is no blocking peek call in the
>> java.util.concurrent.BlockingQueue interface?
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest