On Sat, 2017-03-18 at 14:29 +0900, Tristan Van Berkom wrote: > On Fri, 2017-03-17 at 14:26 +0100, Emmanuel Pacaud wrote: > > > > Le ven. 17 mars 2017 à 9:52, Emmanuel Pacaud <emmanuel@xxxxxxxxx> > > a > > écrit : > > > > > > > > > Le ven. 17 mars 2017 à 6:43, Tristan Van Berkom > > > <tristan.vanberkom@xxxxxxxxxxxxxxx> 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 ? > > No. Hah. Sorry but this was supposed to be: Yes. Signals are entirely bound to the object on which they were declared, there is no backing out of that :) Cheers, -Tristan _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
