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 _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers