Re: Emitting signals from threads
- Date: Wed, 27 Feb 2019 23:17:52 +0100
- From: Fontana Nicola <ntd@xxxxxxxxx>
- Subject: Re: Emitting signals from threads
Il giorno mar, 08/01/2019 alle 10.02 -0800, Mitko Haralanov via gtk-list ha
> Thanks for the reply.
I find this mail thread really confusing and with a lot of misleading
guesses. As already stated elsewhere, a minimal working example would
likely be a *much* quicker way to solve your problem. I'd also suggest
to start a new clean mail thread.
> One of the main reasons why I am not using g_idle_add() is the timing
> of the callback. I don't want to defer the processing of the callback
> to the "idle" time since this is signal handling related.
g_main_context_invoke is just a wrapper around an idle GSource:
There no magic speed gain in using it instead of g_idle_add: it just
happens to be more convenient.
> Another advantage of g_main_context_invoke[_full]() is that it will
> check the "context" of the caller and, if possible, will call the
> callback directly:
Here rings an alarm bell: you are in a worker thread and you want to
execute some code in the GTK thread; how can you expect that code to be
In another email you said:
> The only thing that the threaded signal callback is doing is changing
> the *model*, which should be allowed.
I don't know what a "threaded signal callback" is, but if with that you
meant code executed in the worker thread, can you please point me where
you got the idea that the model could be changed from outside the GTK
thread? I always thought this was *not* allowed.
Apart from that I still did not understand if you have problems with
threads, with timing, with user interface not updating properly or
gtk-list mailing list