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@xxxxxxxxx> wrote: > > On Tue, 8 Jan 2019 10:02:58 -0800 > Mitko Haralanov via gtk-list <gtk-list@xxxxxxxxx> 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@xxxxxxxxx > https://mail.gnome.org/mailman/listinfo/gtk-list _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
