Re: [Rd] GUI's and R background processes

From: Duncan Murdoch <>
Date: Tue, 15 Jun 2010 12:04:29 -0400

Anne George wrote:
> Hello,
> I am new to R and have created an application using R 2.10, with a graphical UI using TclTk 8.5, running on windows 7, quad core machine.
> The intention of the application is to launch calculations and display results on a graphical dashboard.
> I've reached a roadblock, and I need to confirm that the following CANNOT be done. I've been trying to find a mechanism for doing the following:
> 1. From the dashboard, start a huge calculation (i.e. call a function) that take at least 30 seconds to run, but without tying up the other dashboard features
> 2. Dashboard can detect when the calculation is finished
> 3. Dashboard can display incremental results as the calculation runs (i.e. status/progress)
> The requirement is to kickoff 4 calculations (#1), but I don't want the user to wait for the others to finish.
> The calculations are not dependent. I just need to display results.
> I've been reading that threading in R is not an option. I tried using the multicore package, but that is still synchronous. I looked at multicore, fork(), addTaskCallback(), and TclTk threading, and none of these seem like an option.
> Is there a way to launch multiple R scripts from controller that can communicate back and forth? I believe this means that the separate processes are able to communicate.
> I certainly appreciate any direction you can provide. I really want to find some good news to tell the boss, though, since we went down this path before realizing the limitations.

This is possible, but not easy. You need to work at the C level.

The key is that the long running processes need to periodically tell R to check for user events by calling


at the C level. This works in Windows in current versions, and I believe on all platforms in R-devel.

The code should be prepared for R to call it again during R_ProcessEvents, so if it is not re-entrant, it should arrange to signal an error. It should be prepared for the R_CheckUserInterrupt call to never return if the user happened to interrupt the calculation.

You probably only want one processor to do this, and let it check on the other cores to see if there are any results ready.

Duncan Murdoch mailing list Received on Tue 15 Jun 2010 - 16:11:37 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Tue 15 Jun 2010 - 22:31:08 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive