I’ll try to make it more of a habit to write about Tinymail‘s future enhancements before I commit them. This gives people who are following the project the opportunity to comment on and maybe improve the actual work.
In the good old current days Tinymail’s callbacks for asynchronous operations are guaranteed to happen in the GMainLoop of your application. Tinymail uses a g_idle_add_full and ensures that the operation itself happens in a queue that runs a single thread, and a GCond that ensures that the queue will wait for the callback to happen before entering the next item on the queue.
That’s not enough because a g_idle_add_full does not enter the GDK lock. In near future (the patch is ready), Tinymail will do this too. This will make all of Tinymail’s callback invokes behave like signal handlers of Gtk+ components.
Tinymail’s observer update functions will do the same thing. Although I know you can use glib’s signals for this, I used the original observer pattern for some situations. Usually for situations where it must be clear for the application developer what he’s doing. Just like signal emissions must these update invokes or notifies happen with the GDK lock locked. Next on my list is going after all signal emissions that happen outside of the GDK lock.
The thing with this GDK lock is that it’s completely not well documented, that nearly nobody in the GNOME community fully understands how it works (except maybe people like Tim Janik), how you need to use it and more importantly when you need to do it. It’s at this moment definitely not (yet) clear at all. I started this wiki page in the hopes that our experienced developers will continue improving it. This way we might someday have a real and full description of how to actually correctly use gdk_threads_enter and gdk_threads_leave.