FAQ
I'm having trouble implementing just this. Do you have an implementation
you'd be willing to share? I'd like to have both a blocking and
non-blocking dequeue method.
On Wednesday, October 20, 2010 2:20:57 PM UTC-4, Corey Thomasson wrote:

On 20 October 2010 14:14, roger peppe <rogp...@gmail.com <javascript:>>
wrote:
On 20 October 2010 18:34, Russ Cox <r...@golang.org <javascript:>>
wrote:
Or do you simply use channels themselves as the queue?
Yes, unless you have a specific reason not to.
i wonder if there's room in the standard library for
an unlimited size queue where readers block
if the queue is empty (a slightly harder problem
than the original above).
This seems trivial to implement in my mind, a single goroutine
maintaining a vector of data that does a select{} (if theres data to
send) on an input and output channel, input received goes into the
vector, output goes out on request.
something like that described by the following interface:

type Q interface {
Put(x interface{})
Get() interface{}
Close()
Closed() bool
}

it's not often what you need, but when you do need
it, it's useful to avoid implementing it again.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Kyle Lemons at Aug 12, 2013 at 11:46 pm
    Example code for one is here (created to test out a theory, NOT for actual
    use):
    https://github.com/kylelemons/iq

    I strongly encourage you to not base a solution on infinite queues,
    however. They tend to imply a design flaw elsewhere.

    On Mon, Aug 12, 2013 at 3:40 PM, Scott Nelson wrote:

    I'm having trouble implementing just this. Do you have an implementation
    you'd be willing to share? I'd like to have both a blocking and
    non-blocking dequeue method.
    Channels already have blocking and non-blocking send and receive.

    On Wednesday, October 20, 2010 2:20:57 PM UTC-4, Corey Thomasson wrote:
    On 20 October 2010 14:14, roger peppe wrote:
    On 20 October 2010 18:34, Russ Cox wrote:
    Or do you simply use channels themselves as the queue?
    Yes, unless you have a specific reason not to.
    i wonder if there's room in the standard library for
    an unlimited size queue where readers block
    if the queue is empty (a slightly harder problem
    than the original above).
    This seems trivial to implement in my mind, a single goroutine
    maintaining a vector of data that does a select{} (if theres data to
    send) on an input and output channel, input received goes into the
    vector, output goes out on request.
    something like that described by the following interface:

    type Q interface {
    Put(x interface{})
    Get() interface{}
    Close()
    Closed() bool
    }

    it's not often what you need, but when you do need
    it, it's useful to avoid implementing it again.
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Scott Nelson at Aug 13, 2013 at 2:34 am
    Thanks! You're right...I do want an infinite queue but the in-memory data
    should be bounded and continue on disk.
    On Monday, August 12, 2013 7:46:14 PM UTC-4, Kyle Lemons wrote:

    Example code for one is here (created to test out a theory, NOT for actual
    use):
    https://github.com/kylelemons/iq

    I strongly encourage you to not base a solution on infinite queues,
    however. They tend to imply a design flaw elsewhere.


    On Mon, Aug 12, 2013 at 3:40 PM, Scott Nelson <sc...@scttnlsn.com<javascript:>
    wrote:
    I'm having trouble implementing just this. Do you have an implementation
    you'd be willing to share? I'd like to have both a blocking and
    non-blocking dequeue method.
    Channels already have blocking and non-blocking send and receive.

    On Wednesday, October 20, 2010 2:20:57 PM UTC-4, Corey Thomasson wrote:
    On 20 October 2010 14:14, roger peppe wrote:
    On 20 October 2010 18:34, Russ Cox wrote:
    Or do you simply use channels themselves as the queue?
    Yes, unless you have a specific reason not to.
    i wonder if there's room in the standard library for
    an unlimited size queue where readers block
    if the queue is empty (a slightly harder problem
    than the original above).
    This seems trivial to implement in my mind, a single goroutine
    maintaining a vector of data that does a select{} (if theres data to
    send) on an input and output channel, input received goes into the
    vector, output goes out on request.
    something like that described by the following interface:

    type Q interface {
    Put(x interface{})
    Get() interface{}
    Close()
    Closed() bool
    }

    it's not often what you need, but when you do need
    it, it's useful to avoid implementing it again.
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 12, '13 at 10:40p
activeAug 13, '13 at 2:34a
posts3
users2
websitegolang.org

2 users in discussion

Scott Nelson: 2 posts Kyle Lemons: 1 post

People

Translate

site design / logo © 2021 Grokbase