FAQ
Hi,

This may have been discussed before but would it not be practical to be
able to control the behavior of the underlying channel buffer?

Say you don't want the buffer to block when it is full but simply drop one
of the ends in an either fifo or lifo way.

It could probably be implemented in a wholly backwards compatible way as
perhaps an extra argument to make of type chan.Buffer (or whatever makes
sense)?

What do you think?

/ Henrik

--
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

  • Aram Hăvărneanu at Jan 14, 2014 at 12:41 pm
    No, because it's possible to implement the semantics you need with the
    current channels and slices. It would also be bad because when I see c
    <- foo in code I won't be able to know what it does until I look where
    c is initialised.

    This is a queue that drops old elements: http://play.golang.org/p/VxYNSFmqj4
    For a stack that drops elements (why would you need that?) it's easier
    to use a slice. If you really need it as a channel a goroutine can do
    the translation for you.

    --
    Aram Hăvărneanu

    --
    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.
  • Konstantin Khomoutov at Jan 14, 2014 at 12:58 pm

    On Tue, 14 Jan 2014 13:41:36 +0100 Aram Hăvărneanu wrote: [...]
    This is a queue that drops old elements:
    http://play.golang.org/p/VxYNSFmqj4 For a stack that drops elements
    (why would you need that?)
    Why not? For instance, it's what network routers are supposed to do
    with UDP datagrams when the outbound link is congested.
    UDP is typically used to transmit data which has high redundancy such
    as video streams. If a Go server is used for handling something like
    this, using a queue discipline which only queues until the buffer is
    full and then starts to drop incoming data appears to be reasonable.

    --
    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.
  • Aram Hăvărneanu at Jan 14, 2014 at 1:10 pm

    Why not? For instance, it's what network routers are supposed to do
    with UDP datagrams when the outbound link is congested.
    UDP is typically used to transmit data which has high redundancy such
    as video streams. If a Go server is used for handling something like
    this, using a queue discipline which only queues until the buffer is
    full and then starts to drop incoming data appears to be reasonable.
    Ah, yes, dropping incoming data is very common, and trivial, I though
    the OP meant something else.

    --
    Aram Hăvărneanu

    --
    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.
  • Egon at Jan 14, 2014 at 12:45 pm

    On Tuesday, January 14, 2014 2:07:48 PM UTC+2, Henrik Johansson wrote:
    Hi,

    This may have been discussed before but would it not be practical to be
    able to control the behavior of the underlying channel buffer?

    Say you don't want the buffer to block when it is full but simply drop one
    of the ends in an either fifo or lifo way.
    http://play.golang.org/p/iiktjv_l26

    It could probably be implemented in a wholly backwards compatible way as
    perhaps an extra argument to make of type chan.Buffer (or whatever makes
    sense)?

    What do you think?

    / Henrik
    --
    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.
  • Henrik Johansson at Jan 14, 2014 at 12:58 pm
    My question is not at all related to any real need I have now.
    It was merely a thought I had when refreshing my message passing...

    For example ttl functionality is something easily implemented on a case by
    case but and the ttl on a message clearly belong to the message.
    The dropping of the message feels like it belongs to the queue though.

    Maybe more advanced example would be priorities?

    We are always advocating separation of concerns and I just think that some
    of these approaches may belong in the queuing rather than with the user.


    On Tue, Jan 14, 2014 at 1:45 PM, egon wrote:


    On Tuesday, January 14, 2014 2:07:48 PM UTC+2, Henrik Johansson wrote:

    Hi,

    This may have been discussed before but would it not be practical to be
    able to control the behavior of the underlying channel buffer?

    Say you don't want the buffer to block when it is full but simply drop
    one of the ends in an either fifo or lifo way.
    http://play.golang.org/p/iiktjv_l26

    It could probably be implemented in a wholly backwards compatible way as
    perhaps an extra argument to make of type chan.Buffer (or whatever makes
    sense)?

    What do you think?

    / Henrik

    --
    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.
  • Egon at Jan 14, 2014 at 1:12 pm

    On Tuesday, January 14, 2014 2:58:34 PM UTC+2, Henrik Johansson wrote:
    My question is not at all related to any real need I have now.
    It was merely a thought I had when refreshing my message passing...

    For example ttl functionality is something easily implemented on a case by
    case but and the ttl on a message clearly belong to the message.
    The dropping of the message feels like it belongs to the queue though.

    Maybe more advanced example would be priorities?

    We are always advocating separation of concerns and I just think that some
    of these approaches may belong in the queuing rather than with the user.
    Or rather a separate library.

    I don't think chan was meant for IPC or as a "does everything related to
    queueing and messaging". If you are having these kinds of problems then you
    should probably use a dedicated messaging library/framework... e.g.
    RabbitMQ.

    + egon

    On Tue, Jan 14, 2014 at 1:45 PM, egon <egon...@gmail.com <javascript:>>wrote:
    On Tuesday, January 14, 2014 2:07:48 PM UTC+2, Henrik Johansson wrote:

    Hi,

    This may have been discussed before but would it not be practical to be
    able to control the behavior of the underlying channel buffer?

    Say you don't want the buffer to block when it is full but simply drop
    one of the ends in an either fifo or lifo way.
    http://play.golang.org/p/iiktjv_l26

    It could probably be implemented in a wholly backwards compatible way as
    perhaps an extra argument to make of type chan.Buffer (or whatever makes
    sense)?

    What do you think?

    / Henrik

    --
    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.
  • Henrik Johansson at Jan 14, 2014 at 1:20 pm
    For networking I would go for something else at least until/if net chans
    come back.

    My point is simply that some of these things may belong in the queue.
    Maybe you have a windowing system where communication is distributed via
    channels and you may want to coalesce some events transparently,
    maybe some events are more important?

    It is just food for thought and I am sure there must have been much
    discussion when channels were first conceived.




    On Tue, Jan 14, 2014 at 2:12 PM, egon wrote:


    On Tuesday, January 14, 2014 2:58:34 PM UTC+2, Henrik Johansson wrote:

    My question is not at all related to any real need I have now.
    It was merely a thought I had when refreshing my message passing...

    For example ttl functionality is something easily implemented on a case
    by case but and the ttl on a message clearly belong to the message.
    The dropping of the message feels like it belongs to the queue though.

    Maybe more advanced example would be priorities?

    We are always advocating separation of concerns and I just think that
    some of these approaches may belong in the queuing rather than with the
    user.
    Or rather a separate library.

    I don't think chan was meant for IPC or as a "does everything related to
    queueing and messaging". If you are having these kinds of problems then you
    should probably use a dedicated messaging library/framework... e.g.
    RabbitMQ.

    + egon

    On Tue, Jan 14, 2014 at 1:45 PM, egon wrote:


    On Tuesday, January 14, 2014 2:07:48 PM UTC+2, Henrik Johansson wrote:

    Hi,

    This may have been discussed before but would it not be practical to be
    able to control the behavior of the underlying channel buffer?

    Say you don't want the buffer to block when it is full but simply drop
    one of the ends in an either fifo or lifo way.
    http://play.golang.org/p/iiktjv_l26

    It could probably be implemented in a wholly backwards compatible way
    as perhaps an extra argument to make of type chan.Buffer (or whatever makes
    sense)?

    What do you think?

    / Henrik

    --
    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.

    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.
    --
    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.
  • Minux at Jan 15, 2014 at 2:02 am

    On Tue, Jan 14, 2014 at 8:20 AM, Henrik Johansson wrote:

    For networking I would go for something else at least until/if net chans
    come back.

    My point is simply that some of these things may belong in the queue.
    but the queue doesn't belong to the language, it could (and should) be
    implemented as
    a package.
    Maybe you have a windowing system where communication is distributed via
    channels and you may want to coalesce some events transparently,
    maybe some events are more important?
    All these problems should be fixed in user programs, not on the Go language
    level.
    It is just food for thought and I am sure there must have been much
    discussion when channels were first conceived.
    --
    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.
  • Henrik Johansson at Jan 15, 2014 at 8:11 am
    What queue? I am talking about the channels underlying queue.

    The whole point is to modify the behavior of the channel. If I can do it
    via a library, fine but it is not possible right?

    There would need to be all sorts of intermediary buffers and a number of
    channels. This can easily be implemented in a library, sure but why not
    have it in the native channels? There is already the distinction between
    buffered and non-buffered channels that you have to consider actively when
    you code. This is no different.

    I think it belongs in the language but there could be implementation
    details too destructive to make it worth it of course.
    On Jan 15, 2014 3:02 AM, "minux" wrote:

    On Tue, Jan 14, 2014 at 8:20 AM, Henrik Johansson wrote:

    For networking I would go for something else at least until/if net chans
    come back.

    My point is simply that some of these things may belong in the queue.
    but the queue doesn't belong to the language, it could (and should) be
    implemented as
    a package.
    Maybe you have a windowing system where communication is distributed via
    channels and you may want to coalesce some events transparently,
    maybe some events are more important?
    All these problems should be fixed in user programs, not on the Go
    language level.
    It is just food for thought and I am sure there must have been much
    discussion when channels were first conceived.
    --
    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.
  • Peter Bourgon at Jan 15, 2014 at 9:32 am

    On Wed, Jan 15, 2014 at 9:11 AM, Henrik Johansson wrote:
    What queue? I am talking about the channels underlying queue.

    The whole point is to modify the behavior of the channel. If I can do it via
    a library, fine but it is not possible right?

    There would need to be all sorts of intermediary buffers and a number of
    channels. This can easily be implemented in a library, sure but why not have
    it in the native channels? There is already the distinction between buffered
    and non-buffered channels that you have to consider actively when you code.
    This is no different.

    I think it belongs in the language but there could be implementation details
    too destructive to make it worth it of course.
    Language primitives like channels are building blocks, not prepackaged
    solutions to classes of problems.

    Systems with the semantics you describe are straightforward to
    implement using channels as they exist today.

    http://play.golang.org/p/JyTXqkBxVX
    (Disclaimer: not thoroughly tested.)

    On Jan 15, 2014 3:02 AM, "minux" wrote:


    On Tue, Jan 14, 2014 at 8:20 AM, Henrik Johansson <dahankzter@gmail.com>
    wrote:
    For networking I would go for something else at least until/if net chans
    come back.

    My point is simply that some of these things may belong in the queue.
    but the queue doesn't belong to the language, it could (and should) be
    implemented as
    a package.
    Maybe you have a windowing system where communication is distributed via
    channels and you may want to coalesce some events transparently,
    maybe some events are more important?
    All these problems should be fixed in user programs, not on the Go
    language level.

    It is just food for thought and I am sure there must have been much
    discussion when channels were first conceived.
    --
    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.
    --
    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.
  • Henrik Johansson at Jan 15, 2014 at 9:50 am
    I think the dropping case(s) lifo/fifo is a pretty natural extension to the
    current channels.
    It provides a bit more control of the behavior without sacrificing easy and
    nice way that channels are used.

    1. Unbuffered channels - Rendezvous
    2. Buffered, blocking
    3. Buffered non-blocking - drop newest
    4. Buffered non-blocking - drop oldest

    And sure these can always be implemented (everything can) but that does not
    make it a bad evolution of the channels.




    On Wed, Jan 15, 2014 at 10:32 AM, Peter Bourgon wrote:
    On Wed, Jan 15, 2014 at 9:11 AM, Henrik Johansson wrote:
    What queue? I am talking about the channels underlying queue.

    The whole point is to modify the behavior of the channel. If I can do it via
    a library, fine but it is not possible right?

    There would need to be all sorts of intermediary buffers and a number of
    channels. This can easily be implemented in a library, sure but why not have
    it in the native channels? There is already the distinction between buffered
    and non-buffered channels that you have to consider actively when you code.
    This is no different.

    I think it belongs in the language but there could be implementation details
    too destructive to make it worth it of course.
    Language primitives like channels are building blocks, not prepackaged
    solutions to classes of problems.

    Systems with the semantics you describe are straightforward to
    implement using channels as they exist today.

    http://play.golang.org/p/JyTXqkBxVX
    (Disclaimer: not thoroughly tested.)

    On Jan 15, 2014 3:02 AM, "minux" wrote:


    On Tue, Jan 14, 2014 at 8:20 AM, Henrik Johansson <dahankzter@gmail.com
    wrote:
    For networking I would go for something else at least until/if net
    chans
    come back.

    My point is simply that some of these things may belong in the queue.
    but the queue doesn't belong to the language, it could (and should) be
    implemented as
    a package.
    Maybe you have a windowing system where communication is distributed
    via
    channels and you may want to coalesce some events transparently,
    maybe some events are more important?
    All these problems should be fixed in user programs, not on the Go
    language level.

    It is just food for thought and I am sure there must have been much
    discussion when channels were first conceived.
    --
    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.
    --
    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.
  • Egon at Jan 15, 2014 at 10:04 am

    On Wednesday, January 15, 2014 11:50:02 AM UTC+2, Henrik Johansson wrote:
    I think the dropping case(s) lifo/fifo is a pretty natural extension to
    the current channels.
    It provides a bit more control of the behavior without sacrificing easy
    and nice way that channels are used.

    1. Unbuffered channels - Rendezvous
    2. Buffered, blocking
    3. Buffered non-blocking - drop newest
    4. Buffered non-blocking - drop oldest

    And sure these can always be implemented (everything can) but that does
    not make it a bad evolution of the channels.
    ...and then out of order delivery, then prioritized delivery, then UDP
    style channels that can accept dropped messages... Where should the line be
    drawn?

    If it goes into the language it must have a lot of use-cases; otherwise
    it's better to implement it in a library. If something is really necessary
    in the language you should be able to demonstrate it:
    i.e. a list of 5-15 practical usefulness examples would be a good starting
    point, and then a pro/con analysis for adding that. And not just some
    examples that can be handled by a library... but by examples that will be
    often needed in many variations.

    + egon



    On Wed, Jan 15, 2014 at 10:32 AM, Peter Bourgon <pe...@bourgon.org<javascript:>
    wrote:
    On Wed, Jan 15, 2014 at 9:11 AM, Henrik Johansson <dahan...@gmail.com<javascript:>>
    wrote:
    What queue? I am talking about the channels underlying queue.

    The whole point is to modify the behavior of the channel. If I can do it via
    a library, fine but it is not possible right?

    There would need to be all sorts of intermediary buffers and a number of
    channels. This can easily be implemented in a library, sure but why not have
    it in the native channels? There is already the distinction between buffered
    and non-buffered channels that you have to consider actively when you code.
    This is no different.

    I think it belongs in the language but there could be implementation details
    too destructive to make it worth it of course.
    Language primitives like channels are building blocks, not prepackaged
    solutions to classes of problems.

    Systems with the semantics you describe are straightforward to
    implement using channels as they exist today.

    http://play.golang.org/p/JyTXqkBxVX
    (Disclaimer: not thoroughly tested.)

    On Jan 15, 2014 3:02 AM, "minux" <minu...@gmail.com <javascript:>>
    wrote:

    On Tue, Jan 14, 2014 at 8:20 AM, Henrik Johansson <dahan...@gmail.com<javascript:>
    wrote:
    For networking I would go for something else at least until/if net
    chans
    come back.

    My point is simply that some of these things may belong in the queue.
    but the queue doesn't belong to the language, it could (and should) be
    implemented as
    a package.
    Maybe you have a windowing system where communication is distributed
    via
    channels and you may want to coalesce some events transparently,
    maybe some events are more important?
    All these problems should be fixed in user programs, not on the Go
    language level.

    It is just food for thought and I am sure there must have been much
    discussion when channels were first conceived.
    --
    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...@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.
  • Henrik Johansson at Jan 15, 2014 at 10:13 am
    Yes you are right of course and I subscribe to the usage driven evolution
    of the language.

    I have thought some more and probably the reasonable way would be to either
    provide some Policy interface that the caller could implement and provide
    or just settle for the two lifo/fifo cases in the builtin version.

    I really don't have that many use cases at all since I really don't need it
    myself but the discussion can itself bring other people to find use cases
    that makes sense for them.
    Sometimes you have to have it to see the use case.


    On Wed, Jan 15, 2014 at 11:04 AM, egon wrote:


    On Wednesday, January 15, 2014 11:50:02 AM UTC+2, Henrik Johansson wrote:

    I think the dropping case(s) lifo/fifo is a pretty natural extension to
    the current channels.
    It provides a bit more control of the behavior without sacrificing easy
    and nice way that channels are used.

    1. Unbuffered channels - Rendezvous
    2. Buffered, blocking
    3. Buffered non-blocking - drop newest
    4. Buffered non-blocking - drop oldest

    And sure these can always be implemented (everything can) but that does
    not make it a bad evolution of the channels.
    ...and then out of order delivery, then prioritized delivery, then UDP
    style channels that can accept dropped messages... Where should the line be
    drawn?

    If it goes into the language it must have a lot of use-cases; otherwise
    it's better to implement it in a library. If something is really necessary
    in the language you should be able to demonstrate it:
    i.e. a list of 5-15 practical usefulness examples would be a good starting
    point, and then a pro/con analysis for adding that. And not just some
    examples that can be handled by a library... but by examples that will be
    often needed in many variations.

    + egon


    On Wed, Jan 15, 2014 at 10:32 AM, Peter Bourgon wrote:

    On Wed, Jan 15, 2014 at 9:11 AM, Henrik Johansson <dahan...@gmail.com>
    wrote:
    What queue? I am talking about the channels underlying queue.

    The whole point is to modify the behavior of the channel. If I can do it via
    a library, fine but it is not possible right?

    There would need to be all sorts of intermediary buffers and a number of
    channels. This can easily be implemented in a library, sure but why not have
    it in the native channels? There is already the distinction between buffered
    and non-buffered channels that you have to consider actively when you code.
    This is no different.

    I think it belongs in the language but there could be implementation details
    too destructive to make it worth it of course.
    Language primitives like channels are building blocks, not prepackaged
    solutions to classes of problems.

    Systems with the semantics you describe are straightforward to
    implement using channels as they exist today.

    http://play.golang.org/p/JyTXqkBxVX
    (Disclaimer: not thoroughly tested.)

    On Jan 15, 2014 3:02 AM, "minux" wrote:


    On Tue, Jan 14, 2014 at 8:20 AM, Henrik Johansson <dahan...@gmail.com
    wrote:
    For networking I would go for something else at least until/if net
    chans
    come back.

    My point is simply that some of these things may belong in the queue.
    but the queue doesn't belong to the language, it could (and should) be
    implemented as
    a package.
    Maybe you have a windowing system where communication is distributed
    via
    channels and you may want to coalesce some events transparently,
    maybe some events are more important?
    All these problems should be fixed in user programs, not on the Go
    language level.

    It is just food for thought and I am sure there must have been much
    discussion when channels were first conceived.
    --
    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.
    --
    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.
    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.
    --
    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.
  • Volker Dobler at Jan 15, 2014 at 10:08 am

    Am Mittwoch, 15. Januar 2014 10:50:02 UTC+1 schrieb Henrik Johansson:
    I think the dropping case(s) lifo/fifo is a pretty natural extension to
    the current channels.
    It provides a bit more control of the behavior without sacrificing easy
    and nice way that channels are used.

    1. Unbuffered channels - Rendezvous
    2. Buffered, blocking
    3. Buffered non-blocking - drop newest
    4. Buffered non-blocking - drop oldest

    And sure these can always be implemented (everything can) but that does
    not make it a bad evolution of the channels.
    Seeing code like
         select {
         case channel <- value:
         default:
         }
    I know by looking at 4 local lines of code that value
    won't be sent if nobody is reading from channel or
    channel's buffer is full.

    With some magic internal non-blocking flag I would
    have to consult the definition of channel (which might
    be somewhere else, maybe not even under my control).

    I prefer the local variant and do not see any evolutionary
    advantage of these non-blocking channels.

    V.

    --
    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.
  • Henrik Johansson at Jan 15, 2014 at 10:20 am
    But this does not cover the two additional cases.

    In a truly decoupled design the receiver just eats what it gets and does
    not care who and how the the message got there.
    I know that very often channels are used without any real decoupling but
    rather as a convenient way to shuffle data from one part to another and
    that is fine but I like to entertain the idea of more loosely coupled
    systems.

    I still maintain that it makes sense but as has been pointed out, it should
    carry its weight in terms of usage (not just use cases).



    On Wed, Jan 15, 2014 at 11:08 AM, Volker Dobler
    wrote:
    Am Mittwoch, 15. Januar 2014 10:50:02 UTC+1 schrieb Henrik Johansson:
    I think the dropping case(s) lifo/fifo is a pretty natural extension to
    the current channels.
    It provides a bit more control of the behavior without sacrificing easy
    and nice way that channels are used.

    1. Unbuffered channels - Rendezvous
    2. Buffered, blocking
    3. Buffered non-blocking - drop newest
    4. Buffered non-blocking - drop oldest

    And sure these can always be implemented (everything can) but that does
    not make it a bad evolution of the channels.
    Seeing code like
    select {
    case channel <- value:
    default:
    }
    I know by looking at 4 local lines of code that value
    won't be sent if nobody is reading from channel or
    channel's buffer is full.

    With some magic internal non-blocking flag I would
    have to consult the definition of channel (which might
    be somewhere else, maybe not even under my control).

    I prefer the local variant and do not see any evolutionary
    advantage of these non-blocking channels.

    V.

    --
    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.
  • Dmitry Vyukov at Jan 15, 2014 at 10:30 am

    On Tue, Jan 14, 2014 at 4:07 PM, Henrik Johansson wrote:

    Hi,

    This may have been discussed before but would it not be practical to be
    able to control the behavior of the underlying channel buffer?

    Say you don't want the buffer to block when it is full but simply drop one
    of the ends in an either fifo or lifo way.

    It could probably be implemented in a wholly backwards compatible way as
    perhaps an extra argument to make of type chan.Buffer (or whatever makes
    sense)?

    What do you think?
    You can drop messages using "non-blocking select" today.

    An arbitrary complex overload policies must/can not be implemented in
    runtime. In this case you need an intermidiate dispatcher that will
    reorder/drop messages:

    inc := make(chan *Req, 1000)
    outc := make(chan chan *Req, 1000)
    go func() {
       // dispatcher
       reqs := MakeHeapOrWhatever()
       for {
         select {
         case r := <-inc:
           reqs.Add(r)
         case c := <-outc:
           c <- reqs.Get()
         case <-time.After(...):
           reqs.Tick()
         }
       }
    }()

    for i := 0; i < 10; i++ {
       go func() {
         // consumer
         c := make(chan *Req, 1)
         for {
           outc <- c
           r := <-c
           Process(r)
         }
       }()
    }


    If you are interested in other "simple" cases, then you must be very
    specific and make a very strong case for the extension.

    --
    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.
  • Henrik Johansson at Jan 15, 2014 at 11:17 am
    I think I am mostly (and not even immediately) interested in the dropping
    buffered scenario but I cant make a strong use case for it at this time.

    Could a strong case be performance? Since it can be solved with a buffering
    dispatcher there is no real functional need to include it other than
    perhaps convenience.

    It mostly seems to complete the way channels work today with the two
    additional cases for the buffered versions.

    I will give it a thought, perhaps I can find a case that is not contrived
    as they tend to be when not coming from an immediate need.

    Thanks!


    On Wed, Jan 15, 2014 at 11:30 AM, Dmitry Vyukov wrote:
    On Tue, Jan 14, 2014 at 4:07 PM, Henrik Johansson wrote:

    Hi,

    This may have been discussed before but would it not be practical to be
    able to control the behavior of the underlying channel buffer?

    Say you don't want the buffer to block when it is full but simply drop
    one of the ends in an either fifo or lifo way.

    It could probably be implemented in a wholly backwards compatible way as
    perhaps an extra argument to make of type chan.Buffer (or whatever makes
    sense)?

    What do you think?
    You can drop messages using "non-blocking select" today.

    An arbitrary complex overload policies must/can not be implemented in
    runtime. In this case you need an intermidiate dispatcher that will
    reorder/drop messages:

    inc := make(chan *Req, 1000)
    outc := make(chan chan *Req, 1000)
    go func() {
    // dispatcher
    reqs := MakeHeapOrWhatever()
    for {
    select {
    case r := <-inc:
    reqs.Add(r)
    case c := <-outc:
    c <- reqs.Get()
    case <-time.After(...):
    reqs.Tick()
    }
    }
    }()

    for i := 0; i < 10; i++ {
    go func() {
    // consumer
    c := make(chan *Req, 1)
    for {
    outc <- c
    r := <-c
    Process(r)
    }
    }()
    }


    If you are interested in other "simple" cases, then you must be very
    specific and make a very strong case for the extension.
    --
    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.
  • Dmitry Vyukov at Jan 15, 2014 at 2:39 pm

    On Wed, Jan 15, 2014 at 3:17 PM, Henrik Johansson wrote:
    I think I am mostly (and not even immediately) interested in the dropping
    buffered scenario but I cant make a strong use case for it at this time.

    Could a strong case be performance?
    I guess it depends on details.

    And you can do "drop newest" today with good performance and w/o dispatcher.
    Since it can be solved with a buffering
    dispatcher there is no real functional need to include it other than perhaps
    convenience.

    It mostly seems to complete the way channels work today with the two
    additional cases for the buffered versions.

    I will give it a thought, perhaps I can find a case that is not contrived as
    they tend to be when not coming from an immediate need.

    Thanks!


    On Wed, Jan 15, 2014 at 11:30 AM, Dmitry Vyukov wrote:

    On Tue, Jan 14, 2014 at 4:07 PM, Henrik Johansson <dahankzter@gmail.com>
    wrote:
    Hi,

    This may have been discussed before but would it not be practical to be
    able to control the behavior of the underlying channel buffer?

    Say you don't want the buffer to block when it is full but simply drop
    one of the ends in an either fifo or lifo way.

    It could probably be implemented in a wholly backwards compatible way as
    perhaps an extra argument to make of type chan.Buffer (or whatever makes
    sense)?

    What do you think?
    You can drop messages using "non-blocking select" today.

    An arbitrary complex overload policies must/can not be implemented in
    runtime. In this case you need an intermidiate dispatcher that will
    reorder/drop messages:

    inc := make(chan *Req, 1000)
    outc := make(chan chan *Req, 1000)
    go func() {
    // dispatcher
    reqs := MakeHeapOrWhatever()
    for {
    select {
    case r := <-inc:
    reqs.Add(r)
    case c := <-outc:
    c <- reqs.Get()
    case <-time.After(...):
    reqs.Tick()
    }
    }
    }()

    for i := 0; i < 10; i++ {
    go func() {
    // consumer
    c := make(chan *Req, 1)
    for {
    outc <- c
    r := <-c
    Process(r)
    }
    }()
    }


    If you are interested in other "simple" cases, then you must be very
    specific and make a very strong case for the extension.
    --
    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.
  • Henrik Johansson at Jan 15, 2014 at 2:57 pm
    Is this what you mean?

    if len(c) < cap(c) {
         c <- data
    }

    A bit racy of course but that does not matter I guess.




    On Wed, Jan 15, 2014 at 3:39 PM, Dmitry Vyukov wrote:
    On Wed, Jan 15, 2014 at 3:17 PM, Henrik Johansson wrote:
    I think I am mostly (and not even immediately) interested in the dropping
    buffered scenario but I cant make a strong use case for it at this time.

    Could a strong case be performance?
    I guess it depends on details.

    And you can do "drop newest" today with good performance and w/o
    dispatcher.
    Since it can be solved with a buffering
    dispatcher there is no real functional need to include it other than perhaps
    convenience.

    It mostly seems to complete the way channels work today with the two
    additional cases for the buffered versions.

    I will give it a thought, perhaps I can find a case that is not
    contrived as
    they tend to be when not coming from an immediate need.

    Thanks!


    On Wed, Jan 15, 2014 at 11:30 AM, Dmitry Vyukov wrote:

    On Tue, Jan 14, 2014 at 4:07 PM, Henrik Johansson <dahankzter@gmail.com
    wrote:
    Hi,

    This may have been discussed before but would it not be practical to be
    able to control the behavior of the underlying channel buffer?

    Say you don't want the buffer to block when it is full but simply drop
    one of the ends in an either fifo or lifo way.

    It could probably be implemented in a wholly backwards compatible way
    as
    perhaps an extra argument to make of type chan.Buffer (or whatever
    makes
    sense)?

    What do you think?
    You can drop messages using "non-blocking select" today.

    An arbitrary complex overload policies must/can not be implemented in
    runtime. In this case you need an intermidiate dispatcher that will
    reorder/drop messages:

    inc := make(chan *Req, 1000)
    outc := make(chan chan *Req, 1000)
    go func() {
    // dispatcher
    reqs := MakeHeapOrWhatever()
    for {
    select {
    case r := <-inc:
    reqs.Add(r)
    case c := <-outc:
    c <- reqs.Get()
    case <-time.After(...):
    reqs.Tick()
    }
    }
    }()

    for i := 0; i < 10; i++ {
    go func() {
    // consumer
    c := make(chan *Req, 1)
    for {
    outc <- c
    r := <-c
    Process(r)
    }
    }()
    }


    If you are interested in other "simple" cases, then you must be very
    specific and make a very strong case for the extension.
    --
    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.
  • Dmitry Vyukov at Jan 15, 2014 at 3:31 pm

    On Wed, Jan 15, 2014 at 6:57 PM, Henrik Johansson wrote:
    Is this what you mean?

    if len(c) < cap(c) {
    c <- data
    }

    A bit racy of course but that does not matter I guess.
    No, I mean:

    select {
    case c <- data:
    default:
    }

    Actually, you can do "drop oldest" as well, this time indeed in a
    slightly racy way:

    loop: for {
       select {
       case c <- data:
         break loop
       default:
         select {
         case <-c:
         default:
         }
       }
    }

    This racy-ness (when you recv from an already non-full chan) is fine
    in producer-consumer scenarios with sufficiently buffered channel.


    On Wed, Jan 15, 2014 at 3:39 PM, Dmitry Vyukov wrote:

    On Wed, Jan 15, 2014 at 3:17 PM, Henrik Johansson <dahankzter@gmail.com>
    wrote:
    I think I am mostly (and not even immediately) interested in the
    dropping
    buffered scenario but I cant make a strong use case for it at this time.

    Could a strong case be performance?
    I guess it depends on details.

    And you can do "drop newest" today with good performance and w/o
    dispatcher.
    Since it can be solved with a buffering
    dispatcher there is no real functional need to include it other than
    perhaps
    convenience.

    It mostly seems to complete the way channels work today with the two
    additional cases for the buffered versions.

    I will give it a thought, perhaps I can find a case that is not
    contrived as
    they tend to be when not coming from an immediate need.

    Thanks!



    On Wed, Jan 15, 2014 at 11:30 AM, Dmitry Vyukov <dvyukov@google.com>
    wrote:
    On Tue, Jan 14, 2014 at 4:07 PM, Henrik Johansson
    <dahankzter@gmail.com>
    wrote:
    Hi,

    This may have been discussed before but would it not be practical to
    be
    able to control the behavior of the underlying channel buffer?

    Say you don't want the buffer to block when it is full but simply drop
    one of the ends in an either fifo or lifo way.

    It could probably be implemented in a wholly backwards compatible way
    as
    perhaps an extra argument to make of type chan.Buffer (or whatever
    makes
    sense)?

    What do you think?
    You can drop messages using "non-blocking select" today.

    An arbitrary complex overload policies must/can not be implemented in
    runtime. In this case you need an intermidiate dispatcher that will
    reorder/drop messages:

    inc := make(chan *Req, 1000)
    outc := make(chan chan *Req, 1000)
    go func() {
    // dispatcher
    reqs := MakeHeapOrWhatever()
    for {
    select {
    case r := <-inc:
    reqs.Add(r)
    case c := <-outc:
    c <- reqs.Get()
    case <-time.After(...):
    reqs.Tick()
    }
    }
    }()

    for i := 0; i < 10; i++ {
    go func() {
    // consumer
    c := make(chan *Req, 1)
    for {
    outc <- c
    r := <-c
    Process(r)
    }
    }()
    }


    If you are interested in other "simple" cases, then you must be very
    specific and make a very strong case for the extension.
    --
    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.
  • Henrik Johansson at Jan 15, 2014 at 3:54 pm
    Ah yes with the default block in place the select will not block.
    Sorry Volker I think it was who pointed this out before and I just
    dismissed it. My bad!

    I think I am starting to think it is simple enough as it is.
    The select statement strikes again, it is a very nice thing.

    Thanks!

    On Wed, Jan 15, 2014 at 4:31 PM, Dmitry Vyukov wrote:
    On Wed, Jan 15, 2014 at 6:57 PM, Henrik Johansson wrote:
    Is this what you mean?

    if len(c) < cap(c) {
    c <- data
    }

    A bit racy of course but that does not matter I guess.
    No, I mean:

    select {
    case c <- data:
    default:
    }

    Actually, you can do "drop oldest" as well, this time indeed in a
    slightly racy way:

    loop: for {
    select {
    case c <- data:
    break loop
    default:
    select {
    case <-c:
    default:
    }
    }
    }

    This racy-ness (when you recv from an already non-full chan) is fine
    in producer-consumer scenarios with sufficiently buffered channel.


    On Wed, Jan 15, 2014 at 3:39 PM, Dmitry Vyukov wrote:

    On Wed, Jan 15, 2014 at 3:17 PM, Henrik Johansson <dahankzter@gmail.com
    wrote:
    I think I am mostly (and not even immediately) interested in the
    dropping
    buffered scenario but I cant make a strong use case for it at this
    time.
    Could a strong case be performance?
    I guess it depends on details.

    And you can do "drop newest" today with good performance and w/o
    dispatcher.
    Since it can be solved with a buffering
    dispatcher there is no real functional need to include it other than
    perhaps
    convenience.

    It mostly seems to complete the way channels work today with the two
    additional cases for the buffered versions.

    I will give it a thought, perhaps I can find a case that is not
    contrived as
    they tend to be when not coming from an immediate need.

    Thanks!



    On Wed, Jan 15, 2014 at 11:30 AM, Dmitry Vyukov <dvyukov@google.com>
    wrote:
    On Tue, Jan 14, 2014 at 4:07 PM, Henrik Johansson
    <dahankzter@gmail.com>
    wrote:
    Hi,

    This may have been discussed before but would it not be practical to
    be
    able to control the behavior of the underlying channel buffer?

    Say you don't want the buffer to block when it is full but simply
    drop
    one of the ends in an either fifo or lifo way.

    It could probably be implemented in a wholly backwards compatible
    way
    as
    perhaps an extra argument to make of type chan.Buffer (or whatever
    makes
    sense)?

    What do you think?
    You can drop messages using "non-blocking select" today.

    An arbitrary complex overload policies must/can not be implemented in
    runtime. In this case you need an intermidiate dispatcher that will
    reorder/drop messages:

    inc := make(chan *Req, 1000)
    outc := make(chan chan *Req, 1000)
    go func() {
    // dispatcher
    reqs := MakeHeapOrWhatever()
    for {
    select {
    case r := <-inc:
    reqs.Add(r)
    case c := <-outc:
    c <- reqs.Get()
    case <-time.After(...):
    reqs.Tick()
    }
    }
    }()

    for i := 0; i < 10; i++ {
    go func() {
    // consumer
    c := make(chan *Req, 1)
    for {
    outc <- c
    r := <-c
    Process(r)
    }
    }()
    }


    If you are interested in other "simple" cases, then you must be very
    specific and make a very strong case for the extension.
    --
    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
postedJan 14, '14 at 12:07p
activeJan 15, '14 at 3:54p
posts22
users8
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase