[rkward-cvs] SF.net SVN: rkward:[3885] trunk/rkward/rkward/rbackend/rkrbackend.cpp

tfry at users.sourceforge.net tfry at users.sourceforge.net
Wed Oct 5 05:28:15 UTC 2011


Revision: 3885
          http://rkward.svn.sourceforge.net/rkward/?rev=3885&view=rev
Author:   tfry
Date:     2011-10-05 05:28:15 +0000 (Wed, 05 Oct 2011)
Log Message:
-----------
Add some comments and traces

Modified Paths:
--------------
    trunk/rkward/rkward/rbackend/rkrbackend.cpp

Modified: trunk/rkward/rkward/rbackend/rkrbackend.cpp
===================================================================
--- trunk/rkward/rkward/rbackend/rkrbackend.cpp	2011-10-04 20:27:49 UTC (rev 3884)
+++ trunk/rkward/rkward/rbackend/rkrbackend.cpp	2011-10-05 05:28:15 UTC (rev 3885)
@@ -1040,6 +1040,7 @@
 #ifndef Q_OS_WIN
 static bool backend_was_forked = false;
 void prepareFork () {
+	RK_TRACE (RBACKEND);
 	if (!RKRBackendProtocolBackend::inRThread ()) return;
 
 	// we need to make sure that the transmitter thread does not hold a lock on the mutex!
@@ -1047,6 +1048,7 @@
 }
 
 void completeForkMaster () {
+	RK_TRACE (RBACKEND);
 	if (!RKRBackendProtocolBackend::inRThread ()) return;
 
 	RKRBackend::this_pointer->stdout_stderr_mutex.unlock ();
@@ -1056,6 +1058,8 @@
 
 	// Block SIGCLD in the main thread from now on. I don't fully understand, why, but otherwise, these signals
 	// interrupt the select() call in the fork()ing code of library(parallel)
+	// NOTE: If this turns out to be a problem, another try might be to add restarts to the SIGCLD handler, as
+	// suggested, here: https://bugreports.qt.nokia.com/browse/QTBUG-1787
 	sigset_t new_set;
 	sigemptyset (&new_set);
 	sigaddset (&new_set, SIGCLD);

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





More information about the rkward-tracker mailing list