Re: [Evolution-hackers] Camel Manifesto (update)
On Thu, 2011-02-17 at 18:37 +, 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 0x77d93980 (LWP 9874)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x0034ff00ee2d in e_flag_wait (flag=0x2002220) at e-flag.c:130 #2 0x7fffe387e934 in ews_get_folder_info_sync (store=0x6e42a0 [CamelEwsStore], top=0x1480880 asd, flags=1, error=0x0) at camel-ews-store.c:500 #3 0x0035020508ae in camel_store_get_folder_info (store=0x6e42a0 [CamelEwsStore], top=0x1480880 asd, flags=1, error=0x0) at camel-store.c:1122 #4 0x003505460ce8 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 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel Manifesto (update)
On Sun, 2011-03-13 at 21:32 +, 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 0x77d93980 (LWP 9874)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x0034ff00ee2d in e_flag_wait (flag=0x2002220) at e-flag.c:130 #2 0x7fffe387e934 in ews_get_folder_info_sync (store=0x6e42a0 [CamelEwsStore], top=0x1480880 asd, flags=1, error=0x0) at camel-ews-store.c:500 #3 0x0035020508ae in camel_store_get_folder_info (store=0x6e42a0 [CamelEwsStore], top=0x1480880 asd, flags=1, error=0x0) at camel-store.c:1122 #4 0x003505460ce8 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
Re: [Evolution-hackers] Sqlite cache for address-book storage in EDS
On Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes mbar...@redhat.com wrote: On Thu, 2011-03-10 at 08:13 +0100, Milan Crha wrote: do not forget that the DB cache is compiled conditionally, because some distros do not ship libdb. Using SQLite for this was mentioned months ago, only no-one got time to actually do it, so go for it. Also, as far as I know there is still licensing issues between Berkeley DB's Sleepcat license and [L]GPL, which is how libebackend was born. https://bugzilla.gnome.org/show_bug.cgi?id=465374 I'm +1 on dumping Berkeley DB. Only think of two things: - using binary storage for this kind of data is bad for cases where the binary file breaks, either due to an update/downgrade of the library providing access to it, or just by a crash. It's not so hot with camel as SQLite has there only summary data, but if you want to store also real data in it, then it can be a problem. There are people having issues recovering their data from addressbook storage already, but if you are going to do any change on it, then it would be good to think of that from the beginning. It would be good to store raw vCards in some plain text file(s) which will be indexed by SQLite summary. This plain text file(s) will be then easy to import to evolution if something goes wrong, and with erasing SQLite file user will not loose any valuable data. (I'm thinking of a flat maildir approach here.) Milan raises a good point about binary formats versus text. Would be good for the raw data to remain human readable. Yes, it makes senses to store it that way. If we can index the data in sqlite summary and store VCards in the way we store individual mail data, it should be sufficient.. Okay, this might be a long shot but I'm gonna throw it out there anyway: would it make sense to look at using Xapian to index a directory of raw vCards? Am not sure if its worth doing this for adress-book. Am just making an assumption that the address-book content may not be as huge as mail data. The only address-book data that would be large enough would be GAL (exchange) and SystemAdressBook (groupwise). I think sqlite should suffice in indexing this.. We've been talking about moving to notmuch [1] for mail indexing, and notmuch is built on Xapian. Trying out Xapian for address books might be a good test drive for using it with mail. To be honest, I wont be having that much time for testing this for address-book. Jony was trying to evaluate the performance between sqlite and notmuch mail indexing for mails, any updates there Jony ? - Chenthill. The catch is, Xapian is written in C++. So we'd likely have to hand write our own GObject bindings for it in C. That's what makes it a long shot. But we could look to notmuch even WebKit/GTK+ for examples of binding C++ to C. My C++ is rusty but I still have my Stroustrup text book. [1] http://notmuchmail.org/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
