FAQ
I have the situation where I am reading and writing to a TCPConn.

type MessageStream struct {
conn *net.TCPConn
// Channel on which to publish connection errors
Error chan error
// Channel on which to publish inbound messages
Inbound chan ofp10.Packet
// Channel on which to receive outbound messages
Outbound chan ofp10.Packet
// Channel on which to receive a shutdown command
Shutdown chan bool
}

I can send messages to conn on the Outbound channel, and receive messages
from the conn on the Inbound channel. I have one go routine for each. I
also have a Shutdown channel to single the MessageStream to exit the
treads, and an Error chan to let listening go routines know when the
connection has been torn down. All of the channels are buffered size 1.

func (m *MessageStream) outbound() {
for {
select {
case <- m.Shutdown:
// Cleanup running process.
log.Println("Closing connection:", m.conn.LocalAddr())
m.conn.Close()
return
case msg := <- m.Outbound:
// Forward outbound messages to conn
if _, err := s.conn.ReadFrom(msg); err != nil {
m.Error <- err
m.Shutdown <- true
}
}
}
}

func (m *MessageStream) inbound() {
for {
buf := make([]byte, 512)
if n, err := m.connection.Read(buf); err != nil {
// Likely a read timeout. Send error to any listening
// threads. Trigger shutdown to close outbound loop.
m.Error <- err
m.Shutdown <- true
return
} else {
m.Inbound <- parseBuf(buf)
}
}
}

In the case that an outside thread sends a signal to Shutdown. The outbound
go routine exits and closed the TCPConn. Then on the next TCPConn.Read
attempt an error will be generated and a message will be sent again the the
Shutdown channel, but there will be no one left to receive. Will the
buffered value in the channel hang around or will it be garbage collected?

Also I'm not feeling to confident in this strategy. Is this a reasonable
approach to message parsing?

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/95b9ed15-dd56-4134-9070-61a0dc666d17%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Dave Cheney at Oct 16, 2013 at 3:27 am

    On Wed, Oct 16, 2013 at 2:25 PM, Jonathan Stout wrote:
    I have the situation where I am reading and writing to a TCPConn.

    type MessageStream struct {
    conn *net.TCPConn
    // Channel on which to publish connection errors
    Error chan error
    // Channel on which to publish inbound messages
    Inbound chan ofp10.Packet
    // Channel on which to receive outbound messages
    Outbound chan ofp10.Packet
    // Channel on which to receive a shutdown command
    Shutdown chan bool
    }

    I can send messages to conn on the Outbound channel, and receive messages
    from the conn on the Inbound channel. I have one go routine for each. I also
    have a Shutdown channel to single the MessageStream to exit the treads, and
    an Error chan to let listening go routines know when the connection has been
    torn down. All of the channels are buffered size 1.

    func (m *MessageStream) outbound() {
    for {
    select {
    case <- m.Shutdown:
    // Cleanup running process.
    log.Println("Closing connection:", m.conn.LocalAddr())
    m.conn.Close()
    return
    case msg := <- m.Outbound:
    // Forward outbound messages to conn
    if _, err := s.conn.ReadFrom(msg); err != nil {
    m.Error <- err
    m.Shutdown <- true
    }
    }
    }
    }

    func (m *MessageStream) inbound() {
    for {
    buf := make([]byte, 512)
    if n, err := m.connection.Read(buf); err != nil {
    // Likely a read timeout. Send error to any listening
    // threads. Trigger shutdown to close outbound loop.
    m.Error <- err
    m.Shutdown <- true
    return
    } else {
    m.Inbound <- parseBuf(buf)
    }
    }
    }

    In the case that an outside thread sends a signal to Shutdown. The outbound
    go routine exits and closed the TCPConn. Then on the next TCPConn.Read
    attempt an error will be generated and a message will be sent again the the
    Shutdown channel, but there will be no one left to receive. Will the
    buffered value in the channel hang around or will it be garbage collected?
    Channels, like any other value, are garbage collected when there are
    no remaining references to them.

    Channels are not resources in the way that tcp sockets or files are.
    Also I'm not feeling to confident in this strategy. Is this a reasonable
    approach to message parsing?

    --
    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.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/golang-nuts/95b9ed15-dd56-4134-9070-61a0dc666d17%40googlegroups.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.
    To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANp9fE9xTR4u0h0pZqKWq_QzK6TfKPLYruAjzs4m2xup4Fx2xg%40mail.gmail.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 16, '13 at 3:25a
activeOct 16, '13 at 3:27a
posts2
users2
websitegolang.org

2 users in discussion

Dave Cheney: 1 post Jonathan Stout: 1 post

People

Translate

site design / logo © 2021 Grokbase