On Tuesday, January 20, 2015 at 9:13:52 AM UTC-5, Lars Tørnes Hansen wrote:
Put 'defer resp.Body.Close()' in the top of the function, otherwise resp
is not closed, if err != nil is true
No, Don't do that If err != nil, the Body will be nil, and the defer will

Den mandag den 19. januar 2015 kl. 17.38.20 UTC+1 skrev akib...@gmail.com:
Hi Everyone,

I hope this isn't a duplicate issue but:

I have a number of goroutines that each download a url. After a certain
cutoff point (a timeout), main code execution moves on, leaving goroutines
that didn't finish basically hanging.

See: http://play.golang.org/p/OlPuERL2kQ

Doing this, I'm getting:
/root/.gvm/gos/go1.4rc2/src/net/http/transport.go:945 +0x41d
created by net/http.(*Transport).dialConn
/root/.gvm/gos/go1.4rc2/src/net/http/transport.go:661 +0xcbc
panic: send on closed channel
Is this the entire stack trace? DO you have something that can can reliably
reproduce the panic (preferably without using external web properties)?

I found an SO that suggests that resp.Body is probably causing the issue:
The OP there commented that it was because the Body wasn't being closed.

Is reading resp.Body the likely source of error?
What would be the best way to handle this?

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/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 15 | next ›
Discussion Overview
groupgolang-nuts @
postedJan 19, '15 at 4:38p
activeJan 21, '15 at 3:59p



site design / logo © 2022 Grokbase