<p id="yui_3_16_0_1_1415132548383_2460" dir="ltr">I'm working on a service which dispatches new packets into a threadpool including the active peer from event.peer. The system can then "respond" to each packet within the threadpool based on event.peer if needed. System uses a mutex to insure that only one thread can send at once (per peer) - so recv'ing is synchronized as each recv is be done in main thread, and send'ing is synchronized on per peer basis via per peer mutexs. System is based around a Boost.Asio io_service and currently handles floods of messages from 100 clients in various simulations without issue, processing between 1000 - 10000 messages per second (thats total messages, not messages per peer, with most messages having payloads of 16 - 128 bytes).</p><p id="yui_3_16_0_1_1415132548383_2460" dir="ltr"><br></p><p id="yui_3_16_0_1_1415132548383_2460" dir="ltr">So far, everything is going good. However, I had to go against the grain on this one with many people advising to find a "better" solution and many (yet somehow always varying) suggestions that enet isn't threadsafe (even though the main FAQ says that the host object is the only structure to worry about). So my main question is if I'm missing something that my pop up and bite me at some random point, like incorrect round trip times, lost packets, lost peers, etc. If so, where would be the best place to lock peers while recv'ing and send'ing within the enet lib itself?</p><p id="yui_3_16_0_1_1415132548383_2460" dir="ltr"><br></p>