Is it safer to have this inside the goroutine too? It sends a goaway frame, which means it's sending to resetChan

If you happen to set resetChan's capacity to 0, this hangs unless you move i.conn.Close() inside the goroutine - it's probably safest that way.

Suggesting i.conn.Close is inside the goroutine before the resets? I don't like that hanging is a possibility on Close but I see it is only because the resetChan cannot be read from while this call is done. I will make that update, my main concern was i.conn.streams was updated before Close.

Inside the goroutine after the resets, if that works for you?
On Fri, Feb 27, 2015 at 7:12 PM Derek McGowan notifications@github.com
wrote:

In connection.go
#47 (comment):

@@ -72,11 +72,17 @@ Loop:
timer.Reset(i.timeout)
}
case <-expired:

•       for _, stream := range i.conn.streams {
  

•           stream.Reset()
  

•       }
  

•       i.conn.streamCond.L.Lock()
  

•       streams := i.conn.streams
  

•       i.conn.streams = make(map[spdy.StreamId]*Stream)
  

•       i.conn.streamCond.Broadcast()
  

•       i.conn.streamCond.L.Unlock()
  

•       go func() {
  

•           for _, stream := range streams {
  

•               stream.resetStream()
  

•           }
  

•       }()
      i.conn.Close()
  

Suggesting i.conn.Close is inside the goroutine before the resets? I don't
like that hanging is a possibility on Close but I see it is only because
the resetChan cannot be read from while this call is done. I will make that
update, my main concern was i.conn.streams was updated before Close.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/spdystream/pull/47/files#r25549366.