Deadlock in multi-threaded server

[megabyte1024]

There is a deadlock in a multi-threaded server. The scenario is the following.

I have a unit-test which have a multi-threaded server and a client.

1. Thread utf8 validation #1. The main thread calls the client's endpoint stop method.
2. Thread Sec-Websocket-Origin #2. The server's connection::handle_read_frame method is called with the error = 10054 (Connection reset by peer). The connection mutex is locked in the method start. The m_state is OPEN. The terminate method is called under the "// Other unexpected error" branch.
3. Thread utf8 validation #1. Immediately after the client's stop, the server's endpoint stop method is called. The clean flag is true. The endpoint's mutex is locked. The close_all is called, which calls close for every opened connection. The connection::close method is called and immediately starting to wait when the thread Sec-Websocket-Origin #2 releases the connection mutex.
4. Thread Sec-Websocket-Origin #2. The connection's terminate method calls the endpoint's remove_connection which waits when the thread utf8 validation #1 releases the endpoint's mutex.

Result is the deadlock.

The scenario is quite artificial but who knows may be someone will have similar conditions in a production code and not in a unit-test.

[megabyte1024]

The problem is avoided by calling the server's stop with false as the clean flag.

[shadowncs]

Same goes for the client endpoint. If as a result of a message we stop the endpoint (not from the callback thread) the same deadlock mechanism happens.

This was discovered during development and is not artificial at all. endpoint.stop(true) is dangerous.

[zaphoyd]

As has been discussed in other places, the 0.2.x branch is not particularly safe for use in multithreaded environments. The 0.3.x branch addresses these issues.

[zaphoyd]

Going to close this. If deadlocks are found in 0.3.x+, please report as a new issue. 0.2.x will not receive fixes related to multithreading.