<html><head>
</head>
<body><div>Hi,</div><div><br></div><div>Yes, the signals come from random threads. They come from the thread where the code that caused it to be emitted was running. I think changing that would be an API break, and I think it's not trivial to do it right and guarantee the right ordering.</div><div><br></div><div>I guess ideally, one would move the entire state machine of libnice onto the main thread to make this easier.</div><div><br></div><div>Out of curiosity, what kind of thread races are you seeing?</div><div><br></div><div>Olivier</div><div><br></div><div>On Thu, 2021-05-13 at 11:49 +0200, Juan Navarro wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div> On 13/05/2021 11.34, Lorenzo Miniero wrote:<br> <br></div><blockquote type="cite" cite="mid:CAHEg3BJHKqfhWCcy6E9sW+SAdwvEPcPec3hfFezn0RU-e=SmPw@mail.gmail.com" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div> <meta http-equiv="content-type" content="text/html; charset=UTF-8"></div><div dir="ltr"><div class="gmail_quote"><div>In our case, it was caused by the wrong assumption that the selected-pair callback would always be fired by the same thread as the other libnice events, which turned out not to be true</div></div></div></blockquote><div> <br> Correct, that's exactly what I've observed. I asked here but after some days, I've been thinking to file a bug report, because my code is receiving signals such as "new-candidate-full" from the thread of a "nicesrc" element in the GStreamer pipeline, which seems nonsensical.<br> <br> <br> <br></div><blockquote type="cite" cite="mid:CAHEg3BJHKqfhWCcy6E9sW+SAdwvEPcPec3hfFezn0RU-e=SmPw@mail.gmail.com" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote">As a consequence, we had to refactor the code a bit, so that some things we were doing in place would be performed as a result on messaging on the same loop libnice uses</div></div></blockquote><div> <br> I did something in the same vein; instead of handling the signals directly in a callback, under my original assumption that callbacks would run from the same thread than the NiceAgent's GMainContext, I'm now using "g_main_context_invoke_full()" to push their processing as a second order callback that, this time, does actually run in the mentioned context.<br> <br> However, this didn't solve all thread races. ThreadSanitizer still detects races in the signal emission, but this time the whole stack trace is within glib and libnice code, not passing through any of my code.<br> <br> <br> Thank you very much for the links! I'll have a look to see if there is some idea I didn't think of. And thanks for sharing some feedback, too :)<br> <br> <br> Regards,<br> Juan<br> <br></div><div>_______________________________________________<br></div><div>nice mailing list<br></div><div><a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a><br></div><div><a href="https://lists.freedesktop.org/mailman/listinfo/nice">https://lists.freedesktop.org/mailman/listinfo/nice</a><br></div></blockquote><div><br></div><div><span><pre>-- <br></pre><div data-evo-paragraph="" class="">Olivier Crête</div><div data-evo-paragraph="" class=""><a href="mailto:olivier.crete@collabora.com">olivier.crete@collabora.com</a></div><div data-evo-paragraph="" class=""><br></div></span></div></body></html>