We have floating deadlocks when stop the Acceptor. Firstly deadlocks appear in acceptor.go:354. This connected with fact that session.stop() func is called not once. It can be called from 3 places in acceptor (but static, not dynamic session, could be stopped only once) : acceptor.go:354 and acceptor.go:323 and acceptor.go:129!
That is why after first call session.stop() we write s.admin <- stopReq{} then this s.admin chan processed here in select statement session.go:772 while for !s.Stopped(). and after processing here in session.go:732 we switch s.Stopped to false and quit from select loop and have never listen s.admin more! Second call session.stop() and writing to s.admin calls deadlock((
My proposal is add sync.Once() inside call of session.stop() and write s.admin <- stopReq{} once! Of course we can think more and try to leave only one call of session.stop() such in static session, but sync.Once() is not so bad decision, IMHO)
We have floating deadlocks when stop the Acceptor. Firstly deadlocks appear in acceptor.go:354. This connected with fact that session.stop() func is called not once. It can be called from 3 places in acceptor (but static, not dynamic session, could be stopped only once) : acceptor.go:354 and acceptor.go:323 and acceptor.go:129!
That is why after first call session.stop() we write
s.admin <- stopReq{}
then this s.admin chan processed here in select statement session.go:772 whilefor !s.Stopped()
. and after processing here in session.go:732 we switch s.Stopped to false and quit from select loop and have never listen s.admin more! Second call session.stop() and writing to s.admin calls deadlock(( My proposal is add sync.Once() inside call of session.stop() and write s.admin <- stopReq{} once! Of course we can think more and try to leave only one call of session.stop() such in static session, but sync.Once() is not so bad decision, IMHO)