Le ven. 17 mars 2017 à 9:52, Emmanuel Pacaud <emman...@gnome.org> a
écrit :
Le ven. 17 mars 2017 à 6:43, Tristan Van Berkom
<tristan.vanber...@codethink.co.uk> a écrit :
> On Thu, 2017-03-16 at 10:42 +0100, Emmanuel Pacaud wrote:
>> I have an issue related to the use of g_signal_emit called from an
>> object thread.
>>
>
> 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.
I think I will use this solution.
I have just had a go at implementing something like that, but failed to
find the right way to do it. May be what I want to do is not possible:
Currently, the 'new-buffer' signal is emitted by a ArvStream object,
which leads to the thread join issue I have described. What I would
like to do is to define a signal in ArvStream, but with a signal
callback that doesn't have ArvStream as the first parameter, but an
ArvBuffer. Do the signal callbacks always have the object emiting
instance in their parameters ?
Cheers,
Emmanuel.
_______________________________________________
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
