Re: [Evolution-hackers] threading and soup-based backends

[Not Zed <notzed ximian com>]

PS implementing a fully synchronous api in soup would be a lot lot simpler, although it may have to be an almost completely separate implementation.


On Wed, 2003-12-10 at 11:15 -0500, Dan Winship wrote:
> [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
>
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers