On Mo, 2011-05-16 at 08:11 +0200, Milan Crha wrote: > On Fri, 2011-05-13 at 15:44 +0200, Patrick Ohly wrote: > > In libebook, I get a "Timeout was reached" because the asynchronous > > operation doesn't complete quickly enough. Same for the attempt to > > delete the contacts. The gError->code is 24, which is indeed > > E_BOOK_ERROR_NOT_SUPPORTED. > > Hi, > as long as it's GError, you cannot compare only GError::code, because > the correct way to identify the error is using the whole pair > GError::domain and GError::code. Your domain for "Timeout was reached" > is most likely G_IO_ERROR with a code G_IO_ERROR_TIMED_OUT.
Indeed, that explains it. In principle I know that, I just forgot to check in this case ;-} > The new eclient stuff will not suffer of this (unless some backend will > block main thread for too long). The EClient may not time out, but taking several minutes of 100% CPU time just to safe a handful of contacts just can't be right. > I've no idea about libdb, thus only referring to the error. I have one > notice though, the EBook calls are served and processed mostly as soon > as they come, and they can come "in parallel" too. The backend itself > may make sure that it'll not make any trouble, like by some busy lock. libdb is supposed to be thread-safe, so in theory shouldn't need such a lock. Either libdb is broken or EDS is not using it correctly (wrong environment, for example). Looking at the DB API  I see this flag for opening the environment: DB_INIT_LOCK Initialize the locking subsystem. This subsystem should be used when multiple processes or threads are going to be reading and writing a Berkeley DB database, so that they do not interfere with each other. If all threads are accessing the database(s) read-only, locking is unnecessary. When the DB_INIT_LOCK flag is specified, it is usually necessary to run a deadlock detector, as well. See db_deadlock and DB_ENV->lock_detect() for more information. EDS does not pass this flag, although it has concurrent reads *and* writes. The behavior in that case is undefined as far as I can tell. The downside of using DB_INIT_LOCK is that deadlocks are possible and need to be checked by regularly calling lock_detect(). It might be easier to set DB_INIT_CDB, which enforces multiple reads/single writer access without deadlocks. I'll give that a try.  http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/envopen.html -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers