On Thu, 2017-03-16 at 10:42 +0100, Emmanuel Pacaud wrote: > Hi, > > I have an issue related to the use of g_signal_emit called from an > object thread. > Hi Emmanuel, I dont think there is an easy way out of that. I have used GWeakRef for references that threads make to objects owned by parent thread which may finalize with parent, to solve similar problems, but I dont believe I've tried using signals belonging to a thread spawning object from the thread itself. Another approach, if you want to keep using GSignal, would be to create a different object that is owned completely by the thread. Cheers, -Tristan > The object has a 'new-buffer' signal. It receives data in a thread > it > owns, and emits this signal from this thread. When the object is > finalized, it sets a 'stop' gboolean to TRUE, that tells the thread > to > stop. It then joins the thread, then proceed to ressource > deallocation. > > The problem is g_signal_emit increases the reference count of the > object. That means if the user unref the object from the main thread > (thinking he releases the last reference) during the call to > g_signal_emit, the object is now owned only by the thread. When > g_signal_emit unref the object, the finalization happens on the > object > thread, which will lead to the thread trying to join itself. > > Hence my question: is it possible to emit a signal without > increasing > the reference count of the object ? I'd really like to avoid adding > an > explicit 'stop-the-thread' or 'inhibit-signal' function, to be used > before g_object_unref. > > The code is here: > > https://github.com/AravisProject/aravis/blob/7a024607f812d03ff87a906c > e7f99a1a3bc13b9f/src/arvstream.c > https://github.com/AravisProject/aravis/blob/7a024607f812d03ff87a906c > e7f99a1a3bc13b9f/src/arvuvstream.c > > A fix proposal with an explicit inhibit signal function: > > https://github.com/AravisProject/aravis/pull/51 > > Cheers, > > Emmanuel. > > _______________________________________________ > gtk-list mailing list > gtk-list@xxxxxxxxx > https://mail.gnome.org/mailman/listinfo/gtk-list > _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
