Closed Therzok closed 9 years ago
Any comments on the issues I have raised in the first comment? There are a few things I'd rather not touch myself. Especially the deadlock one seems really really dangerous.
The first one (TryDrain and TryDequeue) isn't an issue. The size is checked a second time inside the lock so state will always remain consistent. If the first check return zero altho size really is larger, that's perfectly valid - if the check returns non-zero altho size is really zero, it will be caught by the second check.
The second issue I'm not sure about. There are no obvious potential deadlocks I can see... the code at line 655 doesn't take any lock on m_connections. However, the code in ExecutePeerShutdown doesn't need to take both locks simultaneously, altho shouldn't be a problem; I fixed it in c42b885e1f4788c46df0841ced1e24b607fe5826.
:+1:
Thanks for fixes!
Best reviewed commit by commit, as they're pretty atomic.
There are a few issues remaining that coverity unveiled, but I didn't touch since I don't have that much expertise in the repository's code.
Specifically,
NetQueue
'sTryDrain
andTryDequeue
are passible to having data races caused by them_size
checks.NetPeer.Internal.cs
seems to be deadlock-able.m_handshakes
->m_connections
starting on line 655 conflicts withNetPeer.Internal.cs
line 375 and line 249 which havem_connections
->m_handshakes
.