[libnice] multithread g_main_loop_quit ad remove agent

[Emanuele Bizzarri]

Hi Philip,
ok we started working on 0.1.7 plus gstreamer 1.3.90.
Using examples we find an issue on test-parse.
stun_message_validate_buffer_length function set 
stun_message_validate_buffer_length_fast return value to var fast_retval.
But fast_retval type is unsigned long and 
stun_message_validate_buffer_length_fast return -1 
(STUN_MESSAGE_BUFFER_INVALID is -1).
So (fast_retval<=0) will be always false.
We have changed fast_retval type (signed long) and now all seems work 
correctly.

But we are still able to crash our application.
Now we are searching a way to get a backtrace.

Some considerations inline.


Il 14/07/2014 09:41, Philip Withnall ha scritto:
 > Otherwise you could cause a deadlock by calling a libnice function on 
that agent from the callback, I think. Olivier knows more about that 
design decision than me though.
Deadlock shold not happen because if I use a libnice function inside the 
callback the mutex will be acquired twice from the same thread and 
released twice at the end of the callback.

Different might be the case if there is an other internal thread that 
use the same mutex.

 >
 > If you want to destroy the user_data in a thread other than the one
 > running the main context you passed to nice_agent_attach_recv(), you
 > need to either:
 >  • implement your own locking on the user_data, or
 >  • (preferably) make it reference counted, and ensure the reference
 > counting functions are thread safe.

Our application is not based on glib, so we are required to destroy 
user_data from another thread.