Closed HypenZou closed 2 years ago
Thank you very much for finding this bug.
But there are still some problems with this PR. The use of conn.timer
is not thread-safe,maybe you just need to check if connection is closed in conn.closeTimeoutConn
, or make conn.timer
to be thread-safe. Both ways have their own advantages.
Thank you very much for finding this bug. But there are still some problems with this PR. The use of
conn.timer
is not thread-safe,maybe you just need to check if connection is closed inconn.closeTimeoutConn
, or makeconn.timer
to be thread-safe. Both ways have their own advantages.
i have added a mutex in Connection
struct to avoid the data race. i think it may work now
Thank you very much for finding this bug. But there are still some problems with this PR. The use of
conn.timer
is not thread-safe,maybe you just need to check if connection is closed inconn.closeTimeoutConn
, or makeconn.timer
to be thread-safe. Both ways have their own advantages.i have added a mutex in
Connection
struct to avoid the data race. i think it may work now
I think atomic.Value is better🤔
Thank you very much for finding this bug. But there are still some problems with this PR. The use of
conn.timer
is not thread-safe,maybe you just need to check if connection is closed inconn.closeTimeoutConn
, or makeconn.timer
to be thread-safe. Both ways have their own advantages.i have added a mutex in
Connection
struct to avoid the data race. i think it may work nowI think atomic.Value is better🤔
yes, you are right , I'm not experienced enough😂
Thank you very much. I merged it.
If I have set the idletime , the timer won't be stoped when the connection closed . The timingwheel still holds the reference to the connection. The connection will not be recyled until it is expired , which may lead memory leak . Especially when the library is designed to handle large numbers of connections in websocket , which means mass connections and long idletime