[R] Running R under Mosix

Luke Tierney luke at nokomis.stat.umn.edu
Thu May 3 15:59:38 CEST 2001


Strange how these things go: we just had a discussion about this very
issue among the R core group yesterday.

On Thu, May 03, 2001 at 11:05:09AM +0100, B.Rowlingson at lancaster.ac.uk wrote:
> The problem is that setjmp and longjmp preserve the signal
> handling context, and any change in signal handling has to 
> be done on the machine that the R process started on. If the
> process has migrated there is some overhead as the remote 
> process communicates back to the original. Because R was
> doing so many setjmp/longjmp calls Mosix decided it wasn't
> worth migrating the process (even to a machine with twice
> the CPU power of the home node).
> 
> I solved the problem by redefining the SETJMP and LONGJMP
> macros in src/include/Defn.h to call _setjmp and _longjmp
> instead. These functions dont preserve the signal context.
> The result was an R executable that migrated and got 99.9%
> CPU time on the twice-as-powerful machine.
> 
>  But, you R-wizards out there, is there any side-effect of
> this change? The man page for setjmp says that the POSIX
> standard doesn't define whether or not the signal context
> is saved so hopefully not. True or false?
> 

POSIX is explicitly not specific about whether setjmp preserves the
signal mask.  On Red Hat prior to 5.0 it did; after 5.0 it did not.
The result: on 5.0 control-C would work exactly once per session.

To deal with this we changed to using sigsetjmp, which takes an
additional boolean argument that specifies whether the signal mask
should be saved or not.  We call it with TRUE to insure that the
signal mask is preserved.  If you want to insure that it is not, you
can change the macro SETJMP macro to call it with false (but you get
one shot at Control-C).

However, Thomas Lumley, who has been using R with Mosix, mentioned
that there is a way you can tell Mosix that it is OK to migrate an R
process even though it makes many of these system calls--I'm sure he
can provide the details of how to do this.

In the longer term it is likely that we will make changes to the
control flow in R that reduce the number of setjmp's and at the same
time we can avoid saving the signal mask and just restore it when we
know it has changed.

luke

-- 
Luke Tierney
University of Minnesota                      Phone:           612-625-7843
School of Statistics                         Fax:             612-624-8868
313 Ford Hall, 224 Church St. S.E.           email:      luke at stat.umn.edu
Minneapolis, MN 55455 USA                    WWW:  http://www.stat.umn.edu
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._



More information about the R-help mailing list