<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
On 13/05/2021 11.34, Lorenzo Miniero wrote:<br>
<blockquote type="cite"
cite="mid:CAHEg3BJHKqfhWCcy6E9sW+SAdwvEPcPec3hfFezn0RU-e=SmPw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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>
<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>
<blockquote type="cite"
cite="mid:CAHEg3BJHKqfhWCcy6E9sW+SAdwvEPcPec3hfFezn0RU-e=SmPw@mail.gmail.com">
<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>
<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>
</body>
</html>