RoosterDragon aa3024f1f8 Fix thread-safety and dispose issues in NetworkConnection. ...

- Calling Close() on a TcpClient is documented to also close the underlying sockets and streams for us. This means we can avoid also calling socket.Client.Close() and generating exceptions on mono.
- TcpClient is not thread-safe. However the NetworkStream returned by GetStream() is thread-safe for a single reader/single writer scenario. If we create and dispose the client on the calling thread, and pass the NetworkStream into the thread we spawn for reading, then we can avoid thread-safety issues incurred by trying to Close() the connection from another thread.
- The clean shutdown means we don't need to make the dodgy Thread.Abort() call as it will end normally, and that means we don't need a finalizer to ensure the thread is killed off.
- Refactor how receivedPackets work in EchoConnection to avoid lock(this).
- Mark connectionState and clientId as volatile since they are set from another thread.

2017-02-21 14:10:06 +00:00

5.9 KiB

Raw Blame History

View Raw