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

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

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. This means,
for GDBus calls, that the call didn't finish in a default time, the
server side didn't reply to the method invocation on time. (As Patrick
suggested too).

The new eclient stuff will not suffer of this (unless some backend will
block main thread for too long). As a workaround, in 3.0, was added
e_data_server_util_set_dbus_call_timeout(), which can be called by

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.
The sync calendar backend does this differently, it has a flag for using
such internal busy lock, thus no call can overlap with another, if the
backend implementation wishes to do so. I guess this kind of
functionality might be useful when added to EBookBackendSync too.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]