Re: [Evolution-hackers] libdb performance issue? (was: Re: libebook: errors when using asynchronous contact addition/removal functions)

[Patrick Ohly <patrick ohly gmx de>]

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 [1] 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.

[1] http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/envopen.html

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/