Skip to content

running R commands asynchronously

5 messages · Richard M. Heiberger, Greg Snow, Brian Ripley +1 more

Original
Greg Snow
# 
Tk windows run asynchronous to the rest of R, so you could write a small function that lets you type the command into a Tk window and runs it while you continue to work in the main R, then the window could signal you when the function finishes.

-----Original Message-----
From: r-help-bounces at r-project.org [mailto:r-help-bounces at r-project.org] On Behalf Of Richard M. Heiberger
Sent: Friday, June 10, 2011 3:30 PM
To: r-help
Subject: [R] running R commands asynchronously

I am interested in running R commands asynchronously.

My first choice is in the same R session that I am currently in.
Here, the goal would be to run something like

     RunAsynchSameSession(myfunction(), "outputname.rda")

Once RunAsynchSameSession had started myfunction(),
RunAsynchSameSession would complete immediately.  myfunction would
keep going.  It is OK if execution of the myfunction() command
prevents new input to R until it has completed.  The important feature
is that RunAsynchSameSession must tell the progam that called it that
it was done.

Second choice is to start an independent process, BATCH or something
similar, and save the resulting data objects in an .rda file.

     RunAsynchBatch("myfile.r", "outputname.rda")

The RunAsynchBatch would start a batch process and complete
immediately after starting the batch file.  The batch file would run
independently until it was completed.  While I know how to do this,
for example with system(wait=FALSE), I would appreciate seeing a
worked collection of statements, including getting outputname.rda back
to the original R session.  I am working on Windows.

Rich


______________________________________________
R-help at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Brian Ripley
#
On Fri, 10 Jun 2011, Greg Snow wrote:

            

      
      
      
    

        
That is really not advised.  R is not designed to run asynchronous R 
commands and is not protected against quite a lot of things which can 
happen if you try that (many low-level routines are not re-entrant, 
for example).  Allowing callbacks to either run simple things (as 
happens from e.g. the GUI menus) whilst a task is running, or to do 
almost all the running (as happens with a menu system built in Tk) is 
fairly safe just because only one task is likely to run at a time.

For over a decade Duncan TL has promised a facility to run tasks in 
parallel in R (as I recall the estimate at DSC 2001 was 12 months).

So the only safe way at present (and the foreseeable future) is to run 
separate processes.  Packages snow and multicore provide means to do 
that (and to wait for and collect results): in the case of multicore 
the parallel tasks work on a copy of the current session and so you do 
come close to the appearance of running aysnchronous tasks.  (By 
choosing to use Windows you exclude yourself from multicore.)

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Greg Snow
    

    

      
      #
    

  


  

      
Good points, I was going to include something along the lines of don't change any data in the console that is involved in the asynchronous process, but figured Richard was smart enough to not do something like that.  But your points add to that and make it clear for others who read this that don't have the experience to know better.

-----Original Message-----
From: Prof Brian Ripley [mailto:ripley at stats.ox.ac.uk] 
Sent: Friday, June 10, 2011 11:36 PM
To: Greg Snow
Cc: Richard M. Heiberger; r-help
Subject: Re: [R] running R commands asynchronously

        
On Fri, 10 Jun 2011, Greg Snow wrote:

        

            

      
      
      
    

        
That is really not advised.  R is not designed to run asynchronous R 
commands and is not protected against quite a lot of things which can 
happen if you try that (many low-level routines are not re-entrant, 
for example).  Allowing callbacks to either run simple things (as 
happens from e.g. the GUI menus) whilst a task is running, or to do 
almost all the running (as happens with a menu system built in Tk) is 
fairly safe just because only one task is likely to run at a time.

For over a decade Duncan TL has promised a facility to run tasks in 
parallel in R (as I recall the estimate at DSC 2001 was 12 months).

So the only safe way at present (and the foreseeable future) is to run 
separate processes.  Packages snow and multicore provide means to do 
that (and to wait for and collect results): in the case of multicore 
the parallel tasks work on a copy of the current session and so you do 
come close to the appearance of running aysnchronous tasks.  (By 
choosing to use Windows you exclude yourself from multicore.)

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Martin Morgan
    

    

      
      #
    

  


  

      
On 06/10/2011 02:29 PM, Richard M. Heiberger wrote:

            

      
      
      
    

        
somewhere in-between, starting a new R session but keeping the 
communication within the original.

library(snow)
cl <- makeSOCKcluster("localhost")
sendCall(cl[[1]], function(n) { Sys.sleep(n); n }, list(n=5))
## do other things here...
recvResult(cl[[1]]) ## blocks until result available

I had hoped that I could open a non-blocking connection on the master 
(blocking=FALSE in the next-to-last line of newSOCKnode) and then poll 
with isIncomplete(cl[[1]]$con) but I couldn't get this to work (the 
connection, or more likely my understanding, seemed to be blocking anyway).

sendCall(cl[[1]], function(n) { Sys.sleep(n); n }, list(n=5))
while(isIncomplete(cl[[1]]$con))
     cat("tick\n")  ## not printed
recvResult(cl[[1]])

This approach might also work with the multicore package.

Martin