<div dir="ltr"><div><div>Inside enet_host_service(), it may be accessing peers, so you would want to ensure that enet_peer_send() is not being used at that time and so would need one nasty global lock for that.<br><br></div>When not inside a call to enet_host_service(), it is safe to call enet_peer_send() and friends on different peers at once,so long as it is not called on the same peer at one time.<br><br></div>So stupid simplest way would just be to have the one lock guarding everything, host and all peers, and call it quits. More involved solution might be to have a reader-writer lock, with the enet_host_service() locking down things as a writer, and individual peer calls locking the RW lock as readers. Then each peer would be guarded by an individual mutex underneath that. <br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 4, 2014 at 11:18 PM, Jason Lester <span dir="ltr"><<a href="mailto:jasonrlester@yahoo.com" target="_blank">jasonrlester@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p 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 dir="ltr"><br></p><p 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 dir="ltr"><br></p><br>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br></blockquote></div><br></div>