Re: [Evolution-hackers] Camel Manifesto (update)

[David Woodhouse <dwmw2 infradead org>]

On Thu, 2011-02-17 at 18:37 +0000, David Woodhouse wrote:
> I was told today that the GIO (and libsoup) async methods may not be
> called from a thread other than the one running the mainloop. I found a
> stupid race in libsoup¹ and filed a fix, but the bug was closed INVALID
> because apparently it's not *supposed* to be thread-safe.
> 
> That's a serious issue for using it from Evolution; it means we have to
> jump through stupid hoops like using idle callbacks to call it from the
> main thread, just as we do for gconf. 

Ug, and now I've found that that workaround doesn't work either. If we
try to rename a folder, we end up blocking in the main thread, waiting
for the soup request that we deliberately put into an idle function so
that it could run in the main thread...

Thread 1 (Thread 0x7ffff7d93980 (LWP 9874)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00000034ff00ee2d in e_flag_wait (flag=0x2002220) at e-flag.c:130
#2  0x00007fffe387e934 in ews_get_folder_info_sync (store=0x6e42a0 [CamelEwsStore], top=0x1480880 "asd", flags=1, error=0x0) at camel-ews-store.c:500
#3  0x00000035020508ae in camel_store_get_folder_info (store=0x6e42a0 [CamelEwsStore], top=0x1480880 "asd", flags=1, error=0x0) at camel-store.c:1122
#4  0x0000003505460ce8 in folder_tree_cell_edited_cb (folder_tree=<value optimized out>, path_string=<value optimized out>, new_name=0x1ca6460 "asd") at em-folder-tree.c:624

As before, I would prefer to *fix* the broken locking, so that we can
call the soup functions from any thread. But if I'm still not allowed to
do that, what's the best way to fix this deadlock?

-- 
dwmw2