Re: Signal emission from an object thread

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

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 gnome org>
> > a 
> > écrit :
> > > Le ven. 17 mars 2017 à 6:43, Tristan Van Berkom
> > > <tristan vanberkom 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 ?
>
> 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