Re: Emitting signals from threads

On Wed, 27 Feb 2019 14:08:34 -0800
Mitko Haralanov <voidtrance gmail com> wrote:
On Wed, Feb 27, 2019 at 1:10 PM Chris Vine via gtk-list
<gtk-list gnome org> wrote:

On Wed, 27 Feb 2019 09:49:43 -0800
Mitko Haralanov via gtk-list <gtk-list gnome org> wrote:
However, as I understand it, if my signal is running in the main
context, the signal handler should not be running at the same time as
Gtk is recalculating/repainting the TreeView. It seems as if the
threaded signal handler is not running in the main context. The above
behavior is replicated even if I switched to use g_idle_add() instead
of g_main_context_invoke_full().

I am not going to try to penetrate your code, and you may already know
this but a GObject signal handler executes in the thread which emits on
the signal.  If this is a GDK/GTK+ signal, this would/should be, in
almost all cases, the thread in which GTK+ runs, namely the thread
of the default main context.

g_idle_add() does not of itself emit a signal.  It executes a callback
in the main loop of the default main context.

Hi Chris,

I am not expecting g_idle_add() to emit the signal. I am calling a
separate function scheduled by g_idle_add() or
g_main_context_invoke_full(), which does the signal emission. I use
g_idle_add()/g_main_context_invoke_full() to ensure that this callback
is, in fact, running in the main context thread.

However, despite the signal emission occurring in the main context
thread, the signal handler seems to be running at the same time as GTK
internal functions are updating the state of the TreeView columns. As
I understand GTK, this should not be possible.

It depends on what you mean by "at the same time".  They ought not to be
running concurrently in different threads assuming you are not trying
set that up yourself with the deprecated gdk_threads_enter()/leave() and
so forth.  But if the signal handler surrenders control to the main loop
by posting its continuations to the main loop using g_idle_add_full()/
g_main_context_invoke_full() or their cognates, and the "GTK internal
functions ... updating the state of the TreeView columns" to which you
refer do the same, then the continuations may interleave.  Plenty of
GDK drawing works that way, as I understand it.

I am not saying that is what is happening here (I haven't looked at
the code), but it might be.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]