but this is vulnerable to race conditions:

suppose two goroutine run conn.cancel() concurrent, (for example one from timer and one from line-112), name them goroutine-A and goroutine-B.

also suppose we have another concurrent goroutine that run v.Dispatch(), name it goroutine-C.

suppose goroutine-A and goroutine-B pass if entry == v.conn code, but currently only goroutine-A run v.RemoveRay(). (now v.conn is nil)

now suppose goroutine-C run v.getInboundRay before goroutine-B run v.RemoveRay().

so after running v.getInboundRay, v.conn is a new-connection, but now goroutine-B run v.RemoveRay() and it wrongly close the new-connection!!!

///

I know that the probability of this happening is almost zero, but logically is not zero and it should be taken into account.

/////////////////////////////////////////////////////////////////////

also, the v.RemoveRay, should be run, after we're done with dispatcher(defer RemoveRay in socks/shadowsocks/trojan server code)

I can give a rare example where not doing this would cause problems.

and also we should cancel ctx, after udpConn is closed in worker.go.

第一个可以弄
第二个udpconn不可用之后它会自己退出的 要不顶多60秒回收
第三个我也没见tcpconn关了之后强绑定ctx取消 自己管自己的就是了

The second one will exit automatically after udpconn is unavailable, or it will be recycled in 60 seconds at most.

defer udpServer.RemoveRay() cause the outbound-connection close immediately after udpconn is unavailable.

Although it is a rare situation where udpconn is unavailable but outbound-connection is active.

The third one I have never seen before

Canceling ctx cause outbound-pending-Dial close immediately after udpconn is unavailable.

Although it is a rare situation where udpconn is unavailable but outbound-Dial is still pending.

also, if we are in sniffing-state, cause pending-sniffing is closed, and Dial not executed at all.

/////////////

as a result, both are for rare situations, but they are possible anyway and should be fixed.