Skip to content

sending signals to embedded R

13 messages · Deepayan Sarkar, Brian Ripley, Luke Tierney +1 more

Original
Deepayan Sarkar
# 
Hi,

one thing I haven't been able to figure out from R-exts is how to
interrupt a calculation running inside an embedded R. C code inside R
calls R_CheckUserInterrupt() intermittently to check for interrupts,
but how does my GUI tell R that the user wants it interrupted?

-Deepayan
Brian Ripley
#
On Fri, 4 May 2007, Deepayan Sarkar wrote:

            

      
      
      
    

        
Well, the intention is that you send an interrupt, which hardly needs to 
be in the manual.

But SIGINT is caught and used to set R_interrupts_pending = 1, so you 
could risk using that non-API entry point (and be prepared to have your 
GUI broken at any time).

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Deepayan Sarkar
    

    

      
      #
    

  


  

      
On 5/4/07, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:

            

      
      
      
    

        
I didn't mean to imply that it does. I'm just new to signals and
things that should be obvious aren't.

Basically kill(2) seems to be the right thing to use, but I wasn't
sure what the PID needs to be. Turns out sending SIGINT to my GUI from
a shell interrupts R, so raise(SIGINT) should be enough.

-Deepayan

  
  


  


      

    

    

      
      

        


  

        

      Luke Tierney
    

    

      
      #
    

  


  

      
On Fri, 4 May 2007, Deepayan Sarkar wrote:

        

            

      
      
      
    

        
The tricky bit here is figuring out who does the sending.  It you have
a separate thread/process for the GUI and R then that is fine (though
may raise other issues).  If it is a single thread then you need your
event processing to get an occasional look in to recognise the user
action that triggers an interrupt. The Windows version handles this by
having R_CheckUserInterrupt() do a limited amount of event processing
(you need to be careful in GUI events have R actions associated with
them).  I believe the Mac version is similar though it has been a
while since I looked at that. I don't believe the unix version of
R_CheckUserInterrupt() does not provide hooks for installing such
checking (we have talked about this off an on but I don't believe
anything happened -- could be wrong there though).

If Qt allows this one option may be to have events on your nterrupt
widget managed by a small thread that does nothing other than send a
signal to the main thread if the widget is clicked.

Best,

luke

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Fri, 4 May 2007, Luke Tierney wrote:

        

            

      
      
      
    

        
I was assuming that Deepayan's GUI (which seems to need Qt4, BTW, so I was 
unable to compile it) worked via the R-Unix eventloop, in which case it 
gets some CPU time from time to time.

gnomeGUI has an interrupt menu item with action 'onintr', which may well 
be what Deepayan is looking for: the only reason that package still exists 
is to provide example code.  (Not that it was ever properly integrated 
with the R event loop.)

If the issue is what happens when the user Ctrl-C's in the GUI console, 
that depends on what the GUI toolkit does with keyboard input: if it 
generates a SIGINT this should just work, but otherwise the keyboard 
handler needs to be told to call onintr() one way or another.

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Luke Tierney
    

    

      
      #
    

  


  

      
On Sat, 5 May 2007, Prof Brian Ripley wrote:

        

            

      
      
      
    

        
I was assuming that as well.  But my recollection is that on unix the
event loop is only run from within the console reader.  On Windows
(and Mac OS X I believe) some event processing also happens in
R_CheckUserInterrupt(); on Windows there is also some more in some
blocking library calls, like socket reads as I recall.  But unless
things have changed since I last looked none of that happens on unix.

            

      
      
      
    

        
It does have some sort of interrupt device (I can't recall if it is a
menu item or a butto and I can't seem to build a working gnomeGUI to
check). And I believe if you try to use that item (or button?) during
a long-running computation you can't because the events won't be
looked at until R gets back to a console read, at which point the
events will be processed and you jump to the top level (where you
already are).

            

      
      
      
    

        
Again only if the GUI gets a chance to look at the keyboard input,
which I don't think we currently give it.

The UI provided by a shell running in a separate process may not have
a 'G' but it does have its advantages :-)

Best,

luke

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Sat, 5 May 2007, Luke Tierney wrote:

        

            

      
      
      
    

        
That belief is correct (it has a menu item and a button), but my final 
parenthetical remark was that gnomeGUI was not wedged into the event loop.

            

      
      
      
    

        
We builtin the ability for a front-end to register handlers with the R 
event loop, including a polling handler (and that is how we can have a 
Tcl/Tk front end).  That postdates gnomeGUI, which runs the Gtk 
event-loop, not R's.

So my assumption 'worked via the R-Unix eventloop' was that a handler 
(probably a polling handler) had been wedged in the eventloop.
That was in contrast to running under a separate thread.

            

      
      
      
    

        
Or a separate thread, as Rterm.exe does.  Really RGui should also run in a 
separate thread, but when Guido did so, it did not work under Windows 95: 
if we ever give up support for pre-NT Windows I will take a look again at 
this.

I guess my underlying point is that rather than run the GUI from 
R_ProcessEvents (as RGui is), on Unix you can run it from an eventloop 
handler.

Brian

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Luke Tierney
    

    

      
      #
    

  


  

      
On Sat, 5 May 2007, Prof Brian Ripley wrote:

        

            

      
      
      
    

        
I had forgotten about that -- thanks for the reminder.

However, R_PolledEvents is only called from a limited set of places
now (including the socket reading code to keep things responsive
during blocking reads).  But it is not called from the interupt
checking code, which means if a user does something equivalent to

    while (TRUE) {}

there is not point where events get looked at to see a user interrupt
action. The current definition of R_CheckUserInterrupt is

void R_CheckUserInterrupt(void)
{
     R_CheckStack();
     /* This is the point where GUI systems need to do enough event
        processing to determine whether there is a user interrupt event
        pending.  Need to be careful not to do too much event
        processing though: if event handlers written in R are allowed
        to run at this point then we end up with concurrent R
        evaluations and that can cause problems until we have proper
        concurrency support. LT */
#if  ( defined(HAVE_AQUA) || defined(Win32) )
     R_ProcessEvents();
#else
     if (R_interrupts_pending)
         onintr();
#endif /* Win32 */
}

So only on Windows or Mac do we do event processing.  We could add a
R_PolledEvents() call in the #else bit to support this, though the
cautions in the comment do need to be kept in mind.

Best,

luke

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    
1 day later

    

      
      

        


  

        

      Deepayan Sarkar
    

    

      
      #
    

  


  

      
On 5/5/07, Luke Tierney <luke at stat.uiowa.edu> wrote:

            

      
      
      
    

        
Why is that a problem? As far as I can tell, Qt4 can peacefully
coexist with Qt3, and while compiling you just need to use the right
qmake (this is currently hardcoded in the configure script
unfortunately).

Qt4 has been around for a while now, and it's GPL on Windows/Mac as
well as X11, so it seemed like the natural choice.

            

      
      
      
    

        
Is there a reason R_ProcessEvents cannot be set on Unix but can on
Mac? It doesn't seem user-settable on Windows, but whatever the built
in default is seems to handle the Qt event loop. And for that matter,
why is it possible to set the file.edit callback on Mac but not Linux?
This seems arbitrary, and no explanation is given (that I could find).

            

      
      
      
    

        
Yes, that's what I ended up trying, and it seems to work reasonably
well (with one caveat, see below).

My R_PolledEvents calls qApp->processEvents, and if I set the Esc key
to call kill(getpid(), SIGINT) or onintr(), then I can interrupt some
things, like Sys.sleep. But without the patch to make
R_CheckUserInterrupt call R_PolledEvents (or runHandlers) many other
things, like all plotting routines, cannot be interrupted. So, it
would indeed be very helpful to have R_PolledEvents called on Linux,
or allow the setting of the R_ProcessEvents callback.

The problem I'm having with this solution is that whenever I interrupt
a graphics command, R crashes. This is true for commands being
evaluated by R_tryEval, but not those run from the REPL (for example,
if I make the call inside a debug() environment, interrupting it
causes no problems). As far as I can tell, this is only a problem with
graphics; other commands can be interrupted even when run using
R_tryEval().

Running R in a separate thread is a better solution to the GUI
responsiveness issue (and maybe interrupts can be cleanly sent too).
Unfortunately, Qt's threading paradigm doesn't like it when the
process running in the secondary thread (R in this case) tries to run
Qt widgets of its own (e.g. a Qt graphics device). There may be a
general solution to this, but making use of R_CheckUserInterrupt() is
the easier solution for now.

-Deepayan

[...]

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Luke Tierney
    

    

      
      #
    

  


  

      
On Sun, 6 May 2007 deepayan.sarkar at gmail.com wrote:

        

            

      
      
      
    

        
The R_PRocessEvents callback may be settable on MacOS but I'm not sure
it's used -- at least a quick grep didn't reveal its use anywhere
outside the gnuwin32 code.

It would be good to unify the Mac and *nix mechanisms here since the
OS underpinings are now so similar, but it will have to get high
enough on someone's priority list to happen.

Adding the polled events callback is probably not unreasonable at
least as a temporary measure.  It might be useful to think about an
alternate interface that allows code to distinguish a call frm the
interrupt check, which might want to be very fast and not do any more
than necessary to check for an interrupt event, and calbacks in
blocking situations like socket reads.

            

      
      
      
    

        
That sounds like a longjmp being done to a place that doesn't exist --
maybe a threading issue in Qt.  See what gdb tells you about where the
crash is occurring. It might be different for onintr and kill.  You
might also try just setting the R_interrupts_pending flag from the
interrupt event handler rather than calling onintr (which probably
longjmp's) or kill (which may be doing something you don't want if
other threads with other signal handlers are involved).

Best,

luke

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Jeffrey Horner
    

    

      
      #
    

  


  

      
Luke Tierney wrote:

            

      
      
      
    

        
Deepayan, this is your code from quter-20070502 below, where R_tryEval 
is called:

     PROTECT(cmdSexp = mkString(cmd));
     PROTECT(cmdExpr = R_ParseVector(cmdSexp, -1, &status, R_NilValue));
     if (status == PARSE_OK) {
         int i, errorOccurred;
         for(i = 0; i < length(cmdExpr); i++) {
         ans = R_tryEval(VECTOR_ELT(cmdExpr, i),
                 NULL, &errorOccurred);
     }
     if (errorOccurred) ans = R_NilValue;
     UNPROTECT(2);

Question: is each element of cmdExpr actually on the protection stack? 
Or rather, is the caller guaranteed that the cmdExpr element will not be 
garbage collected? My assumption is yes, since cmdExpr is, but I could 
be wrong. Just curious because I just ran into troubles with calling 
R_tryEval with unprotected expressions and accepting signals. I 
witnessed what Luke explained above, that longjmp's were being done to a 
place that I wasn't anticipating, e.g. R_tryEval was never returning.

Jeff

            

      
      
      
    

        

  
    
  


  


      

    

    

      
      

        


  

        

      Deepayan Sarkar
    

    

      
      #
    

  


  

      
On 5/6/07, Jeffrey Horner <jeff.horner at vanderbilt.edu> wrote:

            

      
      
      
    

        
[...]

            

      
      
      
    

        
I meant the callback ptr_R_ProcessEvents (in Rinterface.h).  The Mac
GUI source has (this is probably not the latest version):

dsarkar at kanika:~/Mac-GUI-1.17$ grep -i ptr_r_process */*
REngine/Rinit.c:extern void (*ptr_R_ProcessEvents)();
REngine/Rinit.c:    ptr_R_ProcessEvents =  Re_ProcessEvents;

and R/trunk/src/unix/aqua.c has:

void R_ProcessEvents(void)
{
    if(!useaqua){
        if (R_interrupts_pending)
            onintr();
        return;
    } else
        ptr_R_ProcessEvents();
}

            

      
      
      
    

        
[...]

            

      
      
      
    

        
I will have to start learning about gdb sometime soon, but in this case, the
problem seems to be due to the interaction of R_tryEval() and
graphics, and has nothing to do with interruptions.  Here's a variant
of the trEval test case that triggers a legitimate error caused by

grid.text('foo', gp = gpar(font=1, fontface=1))

dsarkar at kanika:~$ cat tryEvalGraphics.c ## beware of line wrapping

/*
   Compile this as:

RPROG=R-devel

export LD_LIBRARY_PATH=`${RPROG} RHOME`/lib:\${LD_LIBRARY_PATH}
gcc `${RPROG} CMD config --cppflags` \
    `${RPROG} CMD config --ldflags`  \
    -o tryEvalGraphics tryEvalGraphics.c

 */


#include <Rinternals.h>
#include <Rembedded.h>

#include <R_ext/Parse.h>


int
main(int argc, char *argv[])
{
    SEXP e, val;
    int i, errorOccurred;
    ParseStatus status;
    char *cmds[] = {
        "library(lattice)",
        "library(grid)",
        "grid.text('foo', gp = gpar(font=1, fontface=1))",
        "xyplot(1 ~ 1, panel = function() grid.text('foo', gp =
gpar(font=1, fontface=1)))"
    };

    argv[0] = "R";
    Rf_initEmbeddedR(argc, argv);

    for (i = 0; i < 4; i++) {
        printf("** I **: Executing command: %s\n", cmds[i]);
        fflush(stdout); sleep(1);
        PROTECT(e = R_ParseVector(mkString(cmds[i]), -1, &status, R_NilValue));
        val = R_tryEval(VECTOR_ELT(e, 0), NULL, &errorOccurred);
        if (errorOccurred) { Rprintf("Error executing: %s\n", cmds[i]); }
        else Rf_PrintValue(val);
        UNPROTECT(1);
        printf("** I **: Succeeded\n");
        fflush(stdout); sleep(1);
    }

    Rf_endEmbeddedR(0);
    return(0);
}


Running this, I get:


dsarkar at kanika:~$ R-devel CMD ./tryEvalGraphics

R version 2.6.0 Under development (unstable) (2007-05-04 r41439)

[...]

[Previously saved workspace restored]

** I **: Executing command: library(lattice)
[1] "stats"     "graphics"  "grDevices" "utils"     "datasets"  "lattice"
[7] "rcompgen"  "methods"   "base"
** I **: Succeeded
** I **: Executing command: library(grid)
 [1] "grid"      "stats"     "graphics"  "grDevices" "utils"     "datasets"
 [7] "lattice"   "rcompgen"  "methods"   "base"
** I **: Succeeded
** I **: Executing command: grid.text('foo', gp = gpar(font=1, fontface=1))
Error in validGP(list(...)) : Must specify only one of 'font' and 'fontface'
Error executing: grid.text('foo', gp = gpar(font=1, fontface=1))
** I **: Succeeded
** I **: Executing command: xyplot(1 ~ 1, panel = function()
grid.text('foo', gp = gpar(font=1, fontface=1)))
Error in validGP(list(...)) : Must specify only one of 'font' and 'fontface'

 *** caught segfault ***
address 0x22000440, cause 'memory not mapped'

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 3
dsarkar at kanika:~$

Note that the first error (which doesn't actually get around to
starting a device) is handled properly, while the second is not.

[...]

            

      
      
      
    

        
Normally I would say yes, because my understanding is that
sub-elements of protected SEXP's are supposed to be automatically
protected. But I don't really know what happens when there is an
error. On the other hand, I haven't been seeing any errors (other than
the graphics one described above) recently with that code.

One possibly relevant factoid: a few days ago I was trying to play
with R_topLevelExec(), and that seemed to require an extra UNPROTECT()
for no reason (there's a similar hack in rkward). I sort of got it
working, but two consecutive errors reproducibly took me to a
situation where the same error message would get repeated whatever I
did after that. I didn't pursue this because I figured out an
alternative solution to my problem.

-Deepayan

            

      
      
      
    

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Deepayan Sarkar
    

    

      
      #
    

  


  

      
On 5/6/07, Deepayan Sarkar <deepayan.sarkar at gmail.com> wrote:

        

            

      
      
      
    

        
[...]

            

      
      
      
    

        
And running this again with optimization turned off, I get for the last command:

** I **: Executing command: xyplot(1 ~ 1, panel = function()
grid.text('foo', gp = gpar(font=1, fontface=1)))
Error in validGP(list(...)) : Must specify only one of 'font' and 'fontface'
Error: unprotect(): only 0 protected items
** I **: Succeeded

-Deepayan