[rkward-cvs] SF.net SVN: rkward:[3150] branches/2010_10_18_backend_restructuring_branch/ rkward/rbackend

[tfry at users.sourceforge.net]

Revision: 3150
          http://rkward.svn.sourceforge.net/rkward/?rev=3150&view=rev
Author:   tfry
Date:     2010-10-26 08:15:17 +0000 (Tue, 26 Oct 2010)

Log Message:
-----------
fix more mutex troubles

Modified Paths:
--------------
    branches/2010_10_18_backend_restructuring_branch/rkward/rbackend/rembedinternal.cpp
    branches/2010_10_18_backend_restructuring_branch/rkward/rbackend/rthread.cpp

Modified: branches/2010_10_18_backend_restructuring_branch/rkward/rbackend/rembedinternal.cpp
===================================================================
--- branches/2010_10_18_backend_restructuring_branch/rkward/rbackend/rembedinternal.cpp	2010-10-26 06:52:27 UTC (rev 3149)
+++ branches/2010_10_18_backend_restructuring_branch/rkward/rbackend/rembedinternal.cpp	2010-10-26 08:15:17 UTC (rev 3150)
@@ -203,8 +203,8 @@
 				MUTEX_LOCK;
 				if (!(command->type () & RCommand::User)) {
 					RThread::this_pointer->runCommand (command);
+					MUTEX_UNLOCK;
 					RThread::this_pointer->commandFinished ();
-					MUTEX_UNLOCK;
 				} else {
 					// so, we are about to transmit a new user command, which is quite a complex endeavour...
 					/* Some words about running user commands:

Modified: branches/2010_10_18_backend_restructuring_branch/rkward/rbackend/rthread.cpp
===================================================================
--- branches/2010_10_18_backend_restructuring_branch/rkward/rbackend/rthread.cpp	2010-10-26 06:52:27 UTC (rev 3149)
+++ branches/2010_10_18_backend_restructuring_branch/rkward/rbackend/rthread.cpp	2010-10-26 08:15:17 UTC (rev 3150)
@@ -413,6 +413,7 @@
 	/* NOTE: We're keeping separate lists of the items on the search path, and the toplevel symbols in .GlobalEnv here.
 	This info is also present in RObjectList (and it's children). However: a) in a less convenient form, b) in the other thread. To avoid locking, and other complexity, keeping separate lists seems an ok solution. Keep in mind that only the names of only the toplevel objects are kept, here, so the memory overhead should be minimal */
 
+	MUTEX_UNLOCK;
 	bool search_update_needed = false;
 	bool globalenv_update_needed = false;
 
@@ -462,18 +463,14 @@
 		delete dummy;
 	
 		if (search_update_needed) {	// this includes an update of the globalenv, even if not needed
-			MUTEX_UNLOCK;
 			QStringList call = toplevel_env_names;
 			call.prepend ("syncenvs");	// should be faster than the reverse
 			handleSubstackCall (call);
-			MUTEX_LOCK;
 		} 
 		if (globalenv_update_needed) {
-			MUTEX_UNLOCK;
 			QStringList call = global_env_toplevel_names;
 			call.prepend ("syncglobal");	// should be faster than the reverse
 			handleSubstackCall (call);
-			MUTEX_LOCK;
 		}
 	}
 
@@ -485,9 +482,8 @@
 	if (!changed_symbol_names.isEmpty ()) {
 		QStringList call = changed_symbol_names;
 		call.prepend (QString ("sync"));	// should be faster than reverse
-		MUTEX_UNLOCK;
 		handleSubstackCall (call);
-		MUTEX_LOCK;
 		changed_symbol_names.clear ();
 	}
+	MUTEX_LOCK;
 }


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.