Web lists-archives.com

Re: Signal emission from an object thread

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 ?



gtk-list mailing list