[Evolution-hackers] threading and soup-based backends
- From: Dan Winship <danw ximian com>
- To: evolution-hackers ximian com
- Subject: [Evolution-hackers] threading and soup-based backends
- Date: Wed, 10 Dec 2003 11:15:04 -0500
[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
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?
] [Thread Prev