Re: Emitting signals from threads

[Mitko Haralanov <voidtrance gmail com>]

I never said it worked with g_idle_add() (or if I did, I made a typing
mistake). Actually, what I said is that it *doesn't* work with
g_idle_add().

I am not entirely sure what bug "in my code" I could have found since
my code is not responsible for managing and/or painting the columns.
This should be handled entirely in the library. The only thing that
the threaded signal callback is doing is changing the *model*, which
should be allowed. The button click callback is obviously executing
the same code

On Wed, Jan 9, 2019 at 9:37 AM Chris Vine via gtk-list
<gtk-list gnome org> wrote:
> On Tue, 8 Jan 2019 10:02:58 -0800
> Mitko Haralanov via gtk-list <gtk-list gnome org> wrote:
> > Thanks for the reply.
> >
> > When calling g_main_context_invoke_full(), I am using NULL as the
> > context pointer. According to the documentation of
> > g_main_context_invoke():
> >
> >         "If context is NULL then the global default main context — as
> > returned by g_main_context_default() — is used."
> >
> > So, the code should be using the correct context.
> >
> > 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. 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:
> >
> >        "If context is owned by the current thread, function is called
> > directly. Otherwise, if context is the thread-default main context of
> > the current thread and g_main_context_acquire()
> >        succeeds, then function is called and g_main_context_release()
> > is called afterwards.
> >        In any other case, an idle source is created to call function
> > and that source is attached to context (presumably to be run in
> > another thread). The idle source is attached with
> >        G_PRIORITY_DEFAULT priority. If you want a different priority,
> > use g_main_context_invoke_full()."
> >
> > Your suggested implementation is basically the GLib's async queues.
> > Or, may be, a custom event source. However, it seems that
> > g_main_context_invoke_full() should be doing exactly that. With all
> > due respect, I also don't see how it would solve the issue. If the
> > current implementation has an problem with locking/race conditions,
> > would your suggested implementation suffer from the same issue since
> > it's using the same or similar mechanism for calling the callback?
>
> "With all due respect" this is fine, but I am not sure what more your
> interlocutor can say.  If your code works with g_idle_add() but not
> with g_main_context_invoke_full() then you have a timing issue in your
> code caused by the fact that the callbacks for the default main loop via
> g_main_context_invoke_full() may be executed before the callbacks for
> earlier invocations of g_idle_add().
>
> If it doesn't work with either of them then you have some other issue.
> It is possible you have found a bug in glib but more likely you have
> found a bug in your code.
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-list