[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