[Evolution-hackers] threading and soup-based backends

[Dan Winship <danw ximian com>]

[picking up from a conversation on irc]

ORBIT_THREAD_HINT_PER_REQUEST breaks soup-based backends, because soup
does all of its I/O via the glib main loop, so you end up with at least
two problems when you use it from a thread other than the main thread:
     1. soup_session_send_request() sometimes never returns, because the
        request ends up getting handled by the main thread rather than
        the worker thread, so the worker thread gets stuck in
        g_main_iteration() forever.
     2. Various other libsoup calls can fail in various interesting ways
        because they queue an async op and then the main thread manages
        to invoke the callback before the function that queued it
        returns, so you get two functions running concurrently that
        aren't designed to be able to work that way.

The eventual fix is to make soup able to do synchronous non-gmain-based
I/O. (SoupSocket actually can do this, but SoupConnection and
SoupSession can't.) But I don't know if we want to do that now.

Another fix would be to use per-thread main loops, but that would also
be pretty messy.

The simplest short-term fix is probably to make each of the soup-using
methods set up an idle handler, and then do the soup stuff from the idle
handler (which will be run in the main thread). Maybe even make an
ECalBackendSoup and EBookBackendSoup to abstract that out?

-- Dan