Re: Signal emission from an object thread

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

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 gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-list