In the mainloop

[Philip Van Hoof <spam pvanhoof be>]

Hey Guys,

This is the long awaited "you go to the mainloop!" commit. Although we
might still improve bits and pieces of this work, this at least is the
core idea of it.

In both trunk and the sessionwork branch all callbacks that the
application developer invokes will be waited for in the queue. This
implies that the queue is, indeed, as slow as its own operation plus the
callback of the application developer. 

This also implies that the application developer can make the threads of
Tinymail halt (for ever): by making an endless loop in his callback.
Then again, if he does that: his user interface wont redraw caused by
his own programming mistake anyway.

This was done here:

http://tinymail.org/trac/tinymail/changeset/2521

The exact same, after this work, happens with the alerts, the password
questions and the forget password suggestions. These are functions that
you, as application developer, have to implement and therefore functions
that I (or, we), as Tinymail framework developer, have no control over.

At this moment only the sessionwork branch has this, as this work
requires (yes, requires) the new way of initialisation and connecting of
accounts. This work therefore depends on the Modest adaptations that
Sergio started on Friday, which was why we branched Tinymail to that
sessionworker branch.

Right now will they be called from the GMainLoop of gtk+: gtk_main (if
gtk+ is used, of course) with the GDK locks in place correctly. You can
handle them as any other signal callback: without any own GDK locks or
magic instrumentation. Those locks are put there for you, in the
framework.

I'm planning to surround the normal callbacks in the same way too. This
will mean that nearly all gdk_threads_enter and _leave can soon be
patched away from Modest.

You can find the actual commit in the sessionworker branch here:

http://tinymail.org/trac/tinymail/changeset/2529

You can take a look at the GCond type to learn how this has been
implemented. Or you can of course study the two patches.


This can be compared with a poor man's state activity diagram:

-----> = direction of time, each (two) line(s) could be cut and pasted
after the line that came before the line or each line can be seen as a
line invoke by one unique account instance.


+-----------------------+-----------------------+-----------------------------------+
|TnyCamelQueue's Thread |  GMainLoop's Thread   | Synchronisation point  ....       |
+-----------------------+-----------------------+-----------------------------------+

+-----------------------+-----------------------+-----------------------------------+
|Operation ----------------- waiting -------------------------> | Next on the queue |
|       `-------------->| App. Dev's Callback --+-------------> |                   |
|Connect+GetPassFunc-------- waiting -------------------------> | Next on the queue |
|       `-------------->| App. Dev's Callback --+-------------> |                   |
|Connect+ForgetPassFunc----- waiting -------------------------> | Next on the queue |
|       `-------------->| App. Dev's Callback --+-------------> |                   |
|Operation+AlertFunc-------- waiting -------------------------> | Next on the queue |
|       `-------------->| App. Dev's Callback --+-------------> |                   |
|Connect+AlertFunc---------- waiting -------------------------> | Next on the queue |
|       `-------------->| App. Dev's Callback --+-------------> |                   |
+-----------------------+-----------------------+-----------------------------------+



-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog