FAQ
This is *very* interesting!

There also is a matured channel class library in JCSP: Communicating
Sequential Processes for Java. It's matured with respect to offered
functionality as well as having been thoroughly debugged for some 15 years.
See http://www.cs.kent.ac.uk/projects/ofa/jcsp/. Although it's built on
Java, which does not have any channel primitive, the interface might be of
interest.

Personally I'd be thrilled to see 'xchan' also implemented (as a *first*,
up to now it's only been modeled). Have a look at
http://www.teigfam.net/oyvind/pub/pub_details.html#XCHAN

(When that's been done, have a look at 'feathering' - to *avoid* sending
(but Go does not have guards in select, so it's probably not possible or
needed - but it certainly avoids sending unnecessary messages). Have a look
at http://www.teigfam.net/oyvind/pub/pub_details.html#FEATHERING)

Øyvind Teig
Trondheim, Norway
http://www.teigfam.net/oyvind/home/

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

  • Dmitry Vyukov at Jan 13, 2014 at 3:58 am

    On Mon, Jan 13, 2014 at 12:46 AM, Øyvind Teig wrote:
    This is very interesting!

    There also is a matured channel class library in JCSP: Communicating
    Sequential Processes for Java. It's matured with respect to offered
    functionality as well as having been thoroughly debugged for some 15 years.
    See http://www.cs.kent.ac.uk/projects/ofa/jcsp/. Although it's built on
    Java, which does not have any channel primitive, the interface might be of
    interest.

    Personally I'd be thrilled to see 'xchan' also implemented (as a first, up
    to now it's only been modeled). Have a look at
    http://www.teigfam.net/oyvind/pub/pub_details.html#XCHAN
    Hi,

    What problems will it make easier to solve with Go?

    (When that's been done, have a look at 'feathering' - to avoid sending (but
    Go does not have guards in select, so it's probably not possible or needed -
    but it certainly avoids sending unnecessary messages). Have a look at
    http://www.teigfam.net/oyvind/pub/pub_details.html#FEATHERING)
    --
    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.
  • Øyvind Teig at Jan 13, 2014 at 9:04 am
    kl. 04:58:18 UTC+1 mandag 13. januar 2014 skrev Dmitry Vyukov følgende:
    What problems will it make easier to solve with Go?

    Best question there is!

    In the xchan paper's Appendix I have two Go examples (courtesy of
    golang-nuts). However, answering this question I think the golang-nuts
    group would be more qualified to do than I. I have mentioned xchan before
    in this group, but not really suggested it as needed for Go. But then, in
    the scope of this thread I thought it worth mentioning. Observe that the
    two papers are peer reviewed under a rather rigorous regime (CPA).

    The xchan paper also discusses the semantic differences between xchan and
    (output) guards in select. Go does not have the boolean expression of
    guards as first-class citizen, but it can simulate them and thus
    effectively have a flavour of them. Therefore I infer that xchan in Go
    would add something different. And with the introduction of 'feathering' in
    the second paper the difference is even further emphasized. I am not
    certain if feathering could be introduced if it were not for xchan.

    One may view channels as the "goto of communication". In many use cases
    they are used to build higher level patterns like f.ex. some kind of
    transactions. If these patterns are then supported by the language which is
    able to run 'usage checks' on them, then we see that chan is only the
    beginning. The library provided for this thread addresses this, and also
    contains an overflowing channel type, a comon way to try to make matters
    safe. On the occam world we made oveflowing buffers to simulate this.

    The 'xchan' is one such pattern. It joins asynchronous (buffered
    non-blocking) and synchronous (blocking) thinking and practice. xchan
    provides a 'safe' asynchronous mechanism on a synchronized foundation. I
    have used several blog notes recently trying to understand the common view
    that blocking is perceived as 'evil' and asynchronous is all that makes
    sense. I think I have been able to explain. This view is so common that I
    believe it is the main threat to Go, which easily may fail to tell that
    blocking is not evil. Even in golang-nuts I see it often shine through that
    chan needs to be buffered. I added buffering in xchan simply to avoid a red
    cloth to most programmers, but it's not needed. I fail to see any system
    where internal buffering + xchan with no buffering is not best.

    The 'feathering' is also one such pattern - where explicit non-interest
    saves us communications. It's an implicit type of subscription mechanism.

    I have suggested at least one example of xchan use in the paper. A server
    connected to an incoming connection, where the server never ever blocks
    because it empties itself over an xchan. So the server is always able to
    handle a connection. And overflow, flushing, prioritation atc. are handled
    by the server *application*.

    xchan could potentially also help moving Go into the safety-critical
    (embedded) world, but I guess that is a far cry out.

    Øyvind








    --
    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 13, 2014 at 9:42 am

    On Mon, Jan 13, 2014 at 1:04 PM, Øyvind Teig wrote:
    kl. 04:58:18 UTC+1 mandag 13. januar 2014 skrev Dmitry Vyukov følgende:
    What problems will it make easier to solve with Go?

    Best question there is!

    In the xchan paper's Appendix I have two Go examples (courtesy of
    golang-nuts). However, answering this question I think the golang-nuts group
    would be more qualified to do than I. I have mentioned xchan before in this
    group, but not really suggested it as needed for Go. But then, in the scope
    of this thread I thought it worth mentioning. Observe that the two papers
    are peer reviewed under a rather rigorous regime (CPA).

    The xchan paper also discusses the semantic differences between xchan and
    (output) guards in select. Go does not have the boolean expression of guards
    as first-class citizen, but it can simulate them and thus effectively have a
    flavour of them. Therefore I infer that xchan in Go would add something
    different. And with the introduction of 'feathering' in the second paper the
    difference is even further emphasized. I am not certain if feathering could
    be introduced if it were not for xchan.

    One may view channels as the "goto of communication". In many use cases they
    are used to build higher level patterns like f.ex. some kind of
    transactions. If these patterns are then supported by the language which is
    able to run 'usage checks' on them, then we see that chan is only the
    beginning. The library provided for this thread addresses this, and also
    contains an overflowing channel type, a comon way to try to make matters
    safe. On the occam world we made oveflowing buffers to simulate this.

    The 'xchan' is one such pattern. It joins asynchronous (buffered
    non-blocking) and synchronous (blocking) thinking and practice. xchan
    provides a 'safe' asynchronous mechanism on a synchronized foundation. I
    have used several blog notes recently trying to understand the common view
    that blocking is perceived as 'evil' and asynchronous is all that makes
    sense. I think I have been able to explain. This view is so common that I
    believe it is the main threat to Go, which easily may fail to tell that
    blocking is not evil. Even in golang-nuts I see it often shine through that
    chan needs to be buffered. I added buffering in xchan simply to avoid a red
    cloth to most programmers, but it's not needed. I fail to see any system
    where internal buffering + xchan with no buffering is not best.

    The 'feathering' is also one such pattern - where explicit non-interest
    saves us communications. It's an implicit type of subscription mechanism.

    I have suggested at least one example of xchan use in the paper. A server
    connected to an incoming connection, where the server never ever blocks
    because it empties itself over an xchan. So the server is always able to
    handle a connection. And overflow, flushing, prioritation atc. are handled
    by the server application.

    Is it Section 5.2 Local ChanSched ANSI C with Channel-Ready-Channel?
    xchan could potentially also help moving Go into the safety-critical
    (embedded) world, but I guess that is a far cry 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.
  • Øyvind Teig at Jan 13, 2014 at 2:00 pm
    kl. 10:42:17 UTC+1 mandag 13. januar 2014 skrev Dmitry Vyukov følgende:
    On Mon, Jan 13, 2014 at 1:04 PM, Øyvind Teig wrote:

    kl. 04:58:18 UTC+1 mandag 13. januar 2014 skrev Dmitry Vyukov følgende:
    What problems will it make easier to solve with Go?

    Best question there is!

    In the xchan paper's Appendix I have two Go examples (courtesy of
    golang-nuts). However, answering this question I think the golang-nuts group
    would be more qualified to do than I. I have mentioned xchan before in this
    group, but not really suggested it as needed for Go. But then, in the scope
    of this thread I thought it worth mentioning. Observe that the two papers
    are peer reviewed under a rather rigorous regime (CPA).

    The xchan paper also discusses the semantic differences between xchan and
    (output) guards in select. Go does not have the boolean expression of guards
    as first-class citizen, but it can simulate them and thus effectively have a
    flavour of them. Therefore I infer that xchan in Go would add something
    different. And with the introduction of 'feathering' in the second paper the
    difference is even further emphasized. I am not certain if feathering could
    be introduced if it were not for xchan.

    One may view channels as the "goto of communication". In many use cases they
    are used to build higher level patterns like f.ex. some kind of
    transactions. If these patterns are then supported by the language which is
    able to run 'usage checks' on them, then we see that chan is only the
    beginning. The library provided for this thread addresses this, and also
    contains an overflowing channel type, a comon way to try to make matters
    safe. On the occam world we made oveflowing buffers to simulate this.

    The 'xchan' is one such pattern. It joins asynchronous (buffered
    non-blocking) and synchronous (blocking) thinking and practice. xchan
    provides a 'safe' asynchronous mechanism on a synchronized foundation. I
    have used several blog notes recently trying to understand the common view
    that blocking is perceived as 'evil' and asynchronous is all that makes
    sense. I think I have been able to explain. This view is so common that I
    believe it is the main threat to Go, which easily may fail to tell that
    blocking is not evil. Even in golang-nuts I see it often shine through that
    chan needs to be buffered. I added buffering in xchan simply to avoid a red
    cloth to most programmers, but it's not needed. I fail to see any system
    where internal buffering + xchan with no buffering is not best.

    The 'feathering' is also one such pattern - where explicit non-interest
    saves us communications. It's an implicit type of subscription
    mechanism.
    I have suggested at least one example of xchan use in the paper. A server
    connected to an incoming connection, where the server never ever blocks
    because it empties itself over an xchan. So the server is always able to
    handle a connection. And overflow, flushing, prioritation atc. are handled
    by the server application.

    Is it Section 5.2 Local ChanSched ANSI C with Channel-Ready-Channel?
    Yes, but that example is tied to a small embedded system with "hand coded"
    XCHAN and usage of it. The paper suggests a first-class citizen XCHAN, with
    usage checks by the compiler (if possible). Mentioning xchan in this
    golang-nuts thread would be a suggestion to try it out as a channel type in
    package channels.
    xchan could potentially also help moving Go into the safety-critical
    (embedded) world, but I guess that is a far cry 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 13, 2014 at 2:25 pm

    On Mon, Jan 13, 2014 at 6:00 PM, Øyvind Teig wrote:
    kl. 10:42:17 UTC+1 mandag 13. januar 2014 skrev Dmitry Vyukov følgende:
    On Mon, Jan 13, 2014 at 1:04 PM, Øyvind Teig wrote:

    kl. 04:58:18 UTC+1 mandag 13. januar 2014 skrev Dmitry Vyukov følgende:
    What problems will it make easier to solve with Go?

    Best question there is!

    In the xchan paper's Appendix I have two Go examples (courtesy of
    golang-nuts). However, answering this question I think the golang-nuts
    group
    would be more qualified to do than I. I have mentioned xchan before in
    this
    group, but not really suggested it as needed for Go. But then, in the
    scope
    of this thread I thought it worth mentioning. Observe that the two
    papers
    are peer reviewed under a rather rigorous regime (CPA).

    The xchan paper also discusses the semantic differences between xchan
    and
    (output) guards in select. Go does not have the boolean expression of
    guards
    as first-class citizen, but it can simulate them and thus effectively
    have a
    flavour of them. Therefore I infer that xchan in Go would add something
    different. And with the introduction of 'feathering' in the second paper
    the
    difference is even further emphasized. I am not certain if feathering
    could
    be introduced if it were not for xchan.

    One may view channels as the "goto of communication". In many use cases
    they
    are used to build higher level patterns like f.ex. some kind of
    transactions. If these patterns are then supported by the language which
    is
    able to run 'usage checks' on them, then we see that chan is only the
    beginning. The library provided for this thread addresses this, and also
    contains an overflowing channel type, a comon way to try to make matters
    safe. On the occam world we made oveflowing buffers to simulate this.

    The 'xchan' is one such pattern. It joins asynchronous (buffered
    non-blocking) and synchronous (blocking) thinking and practice. xchan
    provides a 'safe' asynchronous mechanism on a synchronized foundation. I
    have used several blog notes recently trying to understand the common
    view
    that blocking is perceived as 'evil' and asynchronous is all that makes
    sense. I think I have been able to explain. This view is so common that
    I
    believe it is the main threat to Go, which easily may fail to tell that
    blocking is not evil. Even in golang-nuts I see it often shine through
    that
    chan needs to be buffered. I added buffering in xchan simply to avoid a
    red
    cloth to most programmers, but it's not needed. I fail to see any system
    where internal buffering + xchan with no buffering is not best.

    The 'feathering' is also one such pattern - where explicit non-interest
    saves us communications. It's an implicit type of subscription
    mechanism.

    I have suggested at least one example of xchan use in the paper. A
    server
    connected to an incoming connection, where the server never ever blocks
    because it empties itself over an xchan. So the server is always able to
    handle a connection. And overflow, flushing, prioritation atc. are
    handled
    by the server application.

    Is it Section 5.2 Local ChanSched ANSI C with Channel-Ready-Channel?
    Yes, but that example is tied to a small embedded system with "hand coded"
    XCHAN and usage of it. The paper suggests a first-class citizen XCHAN, with
    usage checks by the compiler (if possible). Mentioning xchan in this
    golang-nuts thread would be a suggestion to try it out as a channel type in
    package channels.
    xchan could potentially also help moving Go into the safety-critical
    (embedded) world, but I guess that is a far cry out.

    I may be missing something, but it seems to me that the use case is
    already perfectly covered by non-blocking sends in Go:

    for msg := range inchan {
       select {
       case outchan <- msg:
       default:
         // handle overflow (decide what value(s) to discard)
       }
    }

    --
    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.
  • Eapache at Jan 13, 2014 at 3:03 pm
    Xchan looks like a neat concept, but I don't have the time/inclination to implement it myself at the moment.

    --
    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 12, '14 at 8:46p
activeJan 13, '14 at 3:03p
posts7
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase