<div dir="ltr">Sorry for the late reply:P  <div><div><br></div><div>I take <span style="font-size:14px">Curieux Tres's </span>advice and create a new thread to run g_main_loop_run and it works! </div><div>Other operations will never be blocked anymore.</div><div><br></div><div>Thank you guys for the great answers :)<br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-04 8:07 GMT+08:00 Philip Withnall <span dir="ltr"><<a href="mailto:philip@tecnocode.co.uk" target="_blank">philip@tecnocode.co.uk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey,<br>
<span class=""><br>
On Mon, 2015-11-30 at 20:33 +0800, Jack Wang wrote:<br>
> I'm trying to implement ICE on SIP,<br>
> I reference the sdp-example of libnice and want to apply it to my SIP<br>
> codes.<br>
><br>
> The example uses the standard IO to exchange the SDPs,<br>
> but in SIP it needs to listen the response from other side.<br>
><br>
> The question is, before I send INVITE I have to gather ICE<br>
> candidates,<br>
> and wait for signals to proceed. This will block the main process by<br>
> g_main_loop_run(),<br>
> so the SIP procedure can't be triggered normally.<br>
><br>
> But if I remove the g_main_loop_run(),according to the line 162 in<br>
> the example above:<br>
><br>
> while (!exit_thread && !candidate_gathering_done)<br>
> this candidate_gathering_done will never be assigned since the signal<br>
> fail to get through callback function. Is there any non-blocking way<br>
> to multiplex ICE and SIP procedures?<br>
<br>
</span>You can either use threads, as Curieux Tres suggested, which means you<br>
have to be very careful about thread safety, or:<br>
<br>
You can run your entire program inside the main loop. Run<br>
g_main_loop_run() in main(), and don’t do anything else in main().<br>
Start your first operation from a g_idle_add() callback, and connect to<br>
whatever signals you want to wait for from the end of that callback.<br>
Since everything is running inside g_main_loop_run(), this means the<br>
signals will be processed.<br>
<br>
Think of g_main_loop_run() as a poll() call. This is how it is meant to<br>
be used. The way that sdp-example uses it, iterating it manually and<br>
mixing it with threads and condition variables, is pretty horrific and<br>
totally not the way to use GMainLoop.<br>
<br>
There’s some documentation on GMainLoop and related APIs here:<br>
 • <a href="https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.htm" rel="noreferrer" target="_blank">https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.htm</a><br>
l<br>
 • <a href="https://developer.gnome.org/programming-guidelines/unstable/main-con" rel="noreferrer" target="_blank">https://developer.gnome.org/programming-guidelines/unstable/main-con</a><br>
texts.html.en<br>
<span class="HOEnZb"><font color="#888888"><br>
Philip</font></span><br>_______________________________________________<br>
nice mailing list<br>
<a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/nice" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br>
<br></blockquote></div><br></div>