[libnice] Confusion about running threads of signal callbacks

[Juan Navarro]

On 13/05/2021 11.34, Lorenzo Miniero wrote:
> 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

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.


> 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

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.

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.


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 :)


Regards,
Juan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/nice/attachments/20210513/d3d49f87/attachment.htm>