OMG! it's panic

[beaquant]

panic: send on closed channel

goroutine 57799 [running]:
github.com/dgrr/http2.(*Ctx).resolve(0x40f3b6, {0xcc4820, 0xc00008a070})
/root/gopath/pkg/mod/github.com/dgrr/http2@v0.3.4/client.go:58 +0x36
github.com/dgrr/http2.(*Conn).writeLoop.func2.1({0x445d4f, 0xc000682f70}, {0xb1f200, 0xc000b03ce0})
/root/gopath/pkg/mod/github.com/dgrr/http2@v0.3.4/conn.go:414 +0x3d
sync.(*Map).Range(0xc000682f90, 0xc000682e78)
/root/go/src/sync/map.go:346 +0x2aa
github.com/dgrr/http2.(*Conn).writeLoop.func2()
/root/gopath/pkg/mod/github.com/dgrr/http2@v0.3.4/conn.go:412 +0x1bd
github.com/dgrr/http2.(*Conn).writeLoop(0xc001b98b40)
/root/gopath/pkg/mod/github.com/dgrr/http2@v0.3.4/conn.go:471 +0x407
created by github.com/dgrr/http2.(*Conn).Handshake
/root/gopath/pkg/mod/github.com/dgrr/http2@v0.3.4/conn.go:239 +0x7b

[dgrr]

Sad story. I'll take a look as soon as I can. Thanks for reporting.

[dgrr]

Looks like there's a race condition there. The channel is closed because the response has been resolved already.

[hiqsociety]

just went through the code a bit and realised a lot of connecting points. not so simple as it is without following the whole code in detail. my limited opinion will be to use one of the following to "resolve":

1. struct a mutex
2. reference counting
3. spawn into a go routine by itself using https://github.com/panjf2000/ants
4. make a more complicated channel

i expanded my own code and used option 3. with fasthttp for other things when working with fasthttp in this kind of scenario.
the cpu/mem overhead is better than go routines.

just my thoughts BUT i know u'll do better.

[gaby]

@dgrr Any updates on this?

[trajan0x]

https://github.com/diamondcdn/fasthttp-http2 Fixes this