Re: Emitting signals from threads



I could start a new thread but will be confusing for anyone who may be
reading this thread a year from now researching a similar problem.

So, with that said, let me try to clarify:

The application has a GtkTreeView being populated by a GtkTreeModel.
The TreeView has 3 columns, the last one having a GtkCellRenderPixbuf
displaying a "gtk-edit" icon. The TreeView also has a
button-presse-event callback connected, which checks where in the
TreeView the mouse button has clicked and if it happens to be on the
last column/renderer, opens an "Edit" dialog box. One of the other
columns of the TreeView has a GtkCellRendererSpinner attached to it.
This cell render has a cell data function that will "spin" the spinner
when the model gets updated. The GtkTreeModel backing the TreeView
contains a column that is of type guint64. This is the value that
causes the GtkCellRendererSpinner to "spin" when it gets updated.

The actual event which causes the model to get updated is the
application finding a file on the filesystem matching a certain
pattern. This discovery process is happening in a worker thread as to
not block the main UI. In that worker thread, the filesystem is
scanned recursively looking at all files in a directory tree. When a
file matching the pattern is found, a function is scheduled using
g_idle_add()/g_main_context_invoke_full(). This callback is what
actually emits a signal whose handler updates the model.

So, the worker thread is not doing the *real* signal emission. It's
just scheduling a function to run in the main context thread, which
does the *real* signal emission.

As I mentioned in a previous email, I haven't had a lot of time to
create a separate application to show this. I can try to do that if
things are still not clear but I was hoping that the additional
information, which I posted earlier might be useful.

Thank you,
- Mitko

On Wed, Feb 27, 2019 at 2:18 PM Fontana Nicola <ntd entidi it> wrote:

Il giorno mar, 08/01/2019 alle 10.02 -0800, Mitko Haralanov via gtk-list ha
scritto:
Thanks for the reply.
...

Hi,

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:

https://gitlab.gnome.org/GNOME/glib/blob/master/glib/gmain.c#L5854

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
called directly?

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
other.

Ciao.
--
Nicola




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