If connTable.Stop() is called when at least one connection in the table has expired, the connWatcher panics when it receives the stop message from the connTable.
Cause is that when the connWatcher nil-s out its connection both on expiry and when it is stopped; the second nil causes a nil dereference.
Could just do a nil check here, but there's a wider issue that the connWatcher should be GC'd on socket expiry, and it currently isn't. We can't just remove it from the table inline, because we're running on a separate goroutine so this could cause races. So we'll need a dedicated goroutine for the connTable which serializes conn updates and expiries.
rynorris
commented
9 years ago
If connTable.Stop() is called when at least one connection in the table has expired, the connWatcher panics when it receives the stop message from the connTable.
Cause is that when the connWatcher nil-s out its connection both on expiry and when it is stopped; the second nil causes a nil dereference.
Could just do a nil check here, but there's a wider issue that the connWatcher should be GC'd on socket expiry, and it currently isn't. We can't just remove it from the table inline, because we're running on a separate goroutine so this could cause races. So we'll need a dedicated goroutine for the connTable which serializes conn updates and expiries.