On Sun, 2011-03-13 at 21:32 +0000, David Woodhouse wrote: > 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?
We talked about this on IRC already, but for the record EMFolderTree is at fault here for calling a blocking Camel function. folder_tree_cell_edited_cb() instead needs to fetch folder info asynchronously and then do the actual folder rename asynchronously. I've already peppered the function with FIXME comments to this effect. I'll try to follow up on that this week before the code freeze. _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
