Patch: prevents an interlock unreasoning while this folder lock


	This patch prevents an interlock issue on running this code path
while other thread does the last unreason of a folder (and then
folderlocking in uncache folder method).

	Shouldn't all the folder locks be protected by reason unless we surely
know it was already reasoned?
Jose Dapena Paz <jdapena igalia com>
Index: libtinymail-camel/tny-camel-folder.c
--- libtinymail-camel/tny-camel-folder.c	(revision 2472)
+++ libtinymail-camel/tny-camel-folder.c	(working copy)
@@ -1503,6 +1503,9 @@
+	/* we reason the folder to make sure it does not
+	 * lose all the references and uncache, causing an interlock */
+	_tny_camel_folder_reason (priv);
 	g_static_rec_mutex_lock (priv->folder_lock);
 	if (!load_folder_no_lock (priv))
@@ -1541,6 +1544,7 @@
 	g_object_unref (G_OBJECT (headers));
 	g_static_rec_mutex_unlock (priv->folder_lock);
+	_tny_camel_folder_unreason (priv);
 	_tny_session_stop_operation (TNY_FOLDER_PRIV_GET_SESSION (priv));
Index: ChangeLog
--- ChangeLog	(revision 2472)
+++ ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2007-07-17  Jose Dapena Paz  <jdapena igalia com>
+	* libtinymail-camel/tny-camel-folder.c: protect a folder lock
+	with a reason. This prevents some interlock problems, as the
+	last unreason can lead to a folder lock.
 2007-07-13  Philip Van Hoof  <pvanhoof gnome org>
 	* Allowing the POP code to do RETRs while the TOPs are working (while

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