<div dir="ltr"><div><div><div>Good point Lorenzo!!!<br><br></div>This change was added in this commit:<br><br>commit 2faa76a4840100bebd9532bd47a2755874c5b3a0<br>Author: Youness Alaoui <<a href="mailto:youness.alaoui@collabora.co.uk">youness.alaoui@collabora.co.uk</a>><br>Date:   Tue Jun 16 20:40:33 2009 -0400<br><br>    Use a global mutex for all nice agents and use g_source_is_destroyed to avoid the race condition of a source being destroyed while we wait for the mutex<br><br></div>And then the RecMutex was changed by a Mutex in:<br><br>commit 2faa76a4840100bebd9532bd47a2755874c5b3a0<br>Author: Youness Alaoui <<a href="mailto:youness.alaoui@collabora.co.uk">youness.alaoui@collabora.co.uk</a>><br>Date:   Tue Jun 16 20:40:33 2009 -0400<br><br>    Use a global mutex for all nice agents and use g_source_is_destroyed to avoid the race condition of a source being destroyed while we wait for the mutex<br><br></div>It would be interesting rethink a solution using an unique mutex per agent ;).<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-10-05 11:45 GMT+02:00 Lorenzo Miniero <span dir="ltr"><<a href="mailto:lminiero@gmail.com" target="_blank">lminiero@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>we've been working on some stress tests of our Janus WebRTC server, which uses libnice for all the ICE related stuff. While it works great in general, we reach a wall much sooner than we expect, and performance start to degrade quite a bit. By doing some digging and diagnostic in the code we wrote and the one we use, we found out something we thought was weird.</div><div><br></div><div>Specifically, we noticed that the internal method that is used to send packets, nice_agent_send_messages_<wbr>nonblocking (which nice_agent_send itself uses internally) has a lot of code wrapped in an agent_lock()/agent_unlock(), which locks/unlocks a global mutex, and this includes the process of physiclly sending the packet. This means that the whole library is locked until that code is called, which seems overkill. I guess the same happens in other parts of the code as well. I'd understand locking the specific agent if the purpose is thread-safety, but why lock ALL agents at the same time for each packet you send? I tried searching the archives for some info on that, but couldn't find any discussion related to this choice.</div><div><br></div><div>Since I'm already handling thread-safety for most stuff in my own code, is there any way for preventing this from happening? I guess that one possible way could be to retrieve the file descriptor from the agent object and send the packet manually myself, but while this may work in simple (host/prflx/srflx) connectivity, this would definitely not be the case when, for instance, TURN is involved, as that's one of the things the library would take care of for me.</div><div><br></div><div>Looking forward to your thoughts, thanks!<span class="HOEnZb"><font color="#888888"><br>Lorenzo</font></span></div></div>
<br>______________________________<wbr>_________________<br>
nice mailing list<br>
<a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/nice" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/nice</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Miguel París Díaz<br>------------------------------------------------------------------------<br>Computer/Software engineer.<br>Researcher and architect in <a href="http://www.kurento.org" target="_blank">http://www.kurento.org</a><br><a href="http://twitter.com/mparisdiaz" target="_blank">http://twitter.com/mparisdiaz</a><br>------------------------------------------------------------------------<br></div></div>
</div>