You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First let me tell that this is very nice project and a good demonstration of several open source libraries. However, I noticed some small but serious flaws, which cause instability and need to be fixed before it can be used reliably.
The Boost.Asio io_service.run() is called in a worker thread, which means all async signal handlers are also executed on that worker thread. Because of this all async signal handlers execute in parallel with the main thread but the code currently lacks any thread synchronization.
One easy to spot race condition exists for the Client::inMessages deque, which is accessed by Client::read() from the main thread and by the async handler in Client::receive() in a worker thread. There are also races caused by other async signal handlers in both the client and the server code.
A simple fix should be to call io_service::poll() from the main loop instead of calling io_service::run() in a thread, so all async signal handlers are also executed on the main thread. Or of course adding a scoped lock inside all methods.
Another small thing I noticed, which is only slightly related, is that the example_game main loop unnecessarily maxes out one CPU core because it never sleeps.
The text was updated successfully, but these errors were encountered:
First let me tell that this is very nice project and a good demonstration of several open source libraries. However, I noticed some small but serious flaws, which cause instability and need to be fixed before it can be used reliably.
The Boost.Asio io_service.run() is called in a worker thread, which means all async signal handlers are also executed on that worker thread. Because of this all async signal handlers execute in parallel with the main thread but the code currently lacks any thread synchronization.
One easy to spot race condition exists for the Client::inMessages deque, which is accessed by Client::read() from the main thread and by the async handler in Client::receive() in a worker thread. There are also races caused by other async signal handlers in both the client and the server code.
A simple fix should be to call io_service::poll() from the main loop instead of calling io_service::run() in a thread, so all async signal handlers are also executed on the main thread. Or of course adding a scoped lock inside all methods.
Another small thing I noticed, which is only slightly related, is that the example_game main loop unnecessarily maxes out one CPU core because it never sleeps.
The text was updated successfully, but these errors were encountered: