[Evolution-hackers] Some minor Camel API breaks
- From: Matthew Barnes <mbarnes redhat com>
- To: evolution-hackers gnome org
- Subject: [Evolution-hackers] Some minor Camel API breaks
- Date: Mon, 13 Aug 2012 08:19:42 -0400
Just for the record, I made a few API changes to Camel over the weekend.
The changes help increase Camel's thread-safety. One lesson I learned
during the account-mgmt work is when returning a pointer to a reference
counted object in a multi-threaded environment, it's better to return a
new reference to the object which the caller must release. Otherwise it
introduces potential races where the object might be finalized while the
caller is still using it, or before the caller has a chance to reference
it for safe keeping.
Camel gets this wrong almost everywhere.
Here's what I changed:
* camel_session_add_service() now returns a new reference to the newly
added CamelService. The caller must call g_object_unref() on it.
* camel_session_list_services() now returns a list of new references
to available CamelServices. The caller must call g_object_unref()
on each list element before freeing the list.
* camel_session_get_service() is now camel_session_ref_service() and
returns a new reference to a CamelService. The caller must call
g_object_unref() on it.
* Similarly for camel_session_get_service_by_url().
* camel_service_get_settings() is now camel_service_ref_settings() and
returns a new reference to a CamelSettings. The caller must call
g_object_unref() on it.
There's more to be done along these lines but that's all I had in me for
one weekend.
In particular, I still want to rename CamelStore's get_folder() method
to ref_folder() to better reflect its current behavior and since I can
never remember the ownership transfer on that method. But that might
have to wait until 3.7.
Also some miscellaneous changes:
* Realized CamelSession's forward_to() method blocks and needs to be
asynchronous, so I "GIO'ized" it with the usual sync+async pattern.
EMailSession was hacking around this by spawning an async operation
from within its forward_to() method and then immediately returning
TRUE as if the whole forward_to() operation were successful. So it
lies, basically.
* Killed camel_session_lock/unlock(). Exposing mutexes in a public
API is just evil and indicates a bad design. There's still a few
more of these to kill off. 3.7 material, perhaps.
Matt
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]