[libnice] multithread g_main_loop_quit ad remove agent

[Youness Alaoui]

Hi,

Emanuele, there was a bug recently reported by Stephan Thamm which I've
fixed that might interest you :
http://cgit.freedesktop.org/libnice/libnice/commit/?id=287f8a8be697c59acf9700df78eb5070c93d151a
Basically this checks if the recv callback destroyed the stream because if
it did, then it would crash. Unlocking the mutex before calling the
callback or before sending a glib signal is common practice, otherwise you
can't get reentry into your own library, however, the rule is also that
after you lock the mutex again, you must check that your state hasn't
changed since it could be modified between the unlock and the lock, and it
wasn't doing that in the case of the io callback, now that's fixed with
that commit I linked you to.

Philip, about moving libstun to glib, I prefer not to, there was a lot of
work on libstun to make sure it never depends on glib as it's a small lib
and we didn't want to bring the glib dependency with it. The thing is that
it was Nokia paying for development of libstun a few years ago and they
were using it on some of their stuff and "do not depend on glib" was a huge
requirement. We may not care anymore but I'd prefer to keep it the way it
was designed unless necessary, and I think fixing the ssize_t in
win32_common.h is easy to fix and doesn't require to move to glib just yet.

Thanks,
Youness.



On Tue, Jul 15, 2014 at 12:20 PM, Philip Withnall <philip at tecnocode.co.uk>
wrote:

> Yes, I think the best solution would be to eliminate win32_common.h and
> stop reinventing the portability wheel, but I need to get approval from
> the libnice maintainers to do that.
>
> Philip
>
> On Tue, 2014-07-15 at 17:06 +0200, Emanuele Bizzarri wrote:
> > Hi Philip,
> > probably the simpler thing to do is to change the type inside
> win32_common.
> >
> > But you decide.
> >
> > Thank you,
> >
> > Emanuele
> >
> > On 15/07/2014 15:08, Philip Withnall wrote:
> > > On Mon, 2014-07-14 at 15:25 +0200, Emanuele Bizzarri wrote:
> > >> Il 14/07/2014 14:27, Philip Withnall ha scritto:
> > >>> Where *exactly* in the code is this? Looking at my copy of
> > >>> stun/stunmessage.c, the logs show that fast_retval has always had
> type
> > >>> ssize_t (which is signed).
> > >>
> > >> This is the code inside stunmessage.c:
> > > *snip*
> > >
> > > Yup, you've found a bug. My preferred fix would be to make the stun/
> > > library depend on GLib and use GLib types there; the alternative is to
> > > copy the ssize_t configuration code from GLib to the stun/ library and
> > > duplicate it there so that ssize_t is defined correctly.
> > >
> > > Having spoken to Olivier about it, he agrees. Youness, are you OK with
> > > that?
> > >
> > > Philip
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20140724/d79ca71a/attachment-0001.html>