Skip to content

[Rcpp-devel] Interrupts in compiled code.

5 messages · Davor Cubranic, Dirk Eddelbuettel

Davor Cubranic
# 
Hi Dirk,

I have a question about your example on better handling of interrupts with Rcpp: you set the signal handler on entry into the function, but never reset it to the original value. Should that be done as part of the cleanup? What will happen when the function returns to R, whether it was interrupted or not?

Davor
On 2010-12-08, at 1:02 PM, Dirk Eddelbuettel wrote:

            

      
      
      
    

        
...

            

      
      
      
    

  
  


  


    

    

      
      

        


  

        

      Davor Cubranic
    

    

      
      #
    

  


  

      
Actually, the interrupt seems to be caught only the first time I enter "foo". When I call it the second time from the prompt, no handler is activated -- I'm not sure why.

Davor

        
On 2011-01-24, at 3:22 PM, Davor Cubranic wrote:

        

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 24 January 2011 at 15:36, Davor Cubranic wrote:

        
| Actually, the interrupt seems to be caught only the first time I enter "foo". When I call it the second time from the prompt, no handler is activated -- I'm not sure why.

Code such as the one shown below was only ever meant to catch one interrupt
signal such as Ctrl-C for abort. Upon catching the signal I usually wind the
program down.  So I never tried what you are attempting here: to actually be
"reentrant" and catch the same signal multiple times.  Let us know how it
goes and what you find :)

Dirk
 
| Davor
| 
|

        
| On 2011-01-24, at 3:22 PM, Davor Cubranic wrote:

        
| 
| > Hi Dirk,
| > 
| > I have a question about your example on better handling of interrupts with Rcpp: you set the signal handler on entry into the function, but never reset it to the original value. Should that be done as part of the cleanup? What will happen when the function returns to R, whether it was interrupted or not?
| > 
| > Davor
| > 
| >

        
| > On 2010-12-08, at 1:02 PM, Dirk Eddelbuettel wrote:

        
| > 
| >> Here is a simple example that uses a standard C interrupt handler to set a
| >> standard C++ exception to abort:
| > ...
| >> RcppExport SEXP foo(void) {
| >> 
| >> try {
| >> 
| >>   signal(SIGINT, intHandler);
| >>   signal(SIGKILL, intHandler);
| >> [...]
| >> } catch(std::exception &ex) { 
| >>   std::cerr << "In catch of std::exeception" << std::endl;
| >>   // here you insert some clenup
| >>   forward_exception_to_r(ex); 
| >> 
| >> } catch(...) { 
| >>   ::Rf_error("c++ exception (unknown reason)"); 
| >> }
| >> 
| >> return R_NilValue;
| >> }
| > 
| > _______________________________________________
| > Rcpp-devel mailing list
| > Rcpp-devel at lists.r-forge.r-project.org
| > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
|

  
    

      
      
    

  


  


      

    

    
1 day later

    

      
      

        


  

        

      Davor Cubranic
    

    

      
      #
    

  


  

      
On 2011-01-24, at 6:53 PM, Dirk Eddelbuettel wrote:

        

            

      
      
      
    

        
Do you mean that this pattern only applies to stand-alone programs?

Davor

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 26 January 2011 at 16:10, Davor Cubranic wrote:

        
| On 2011-01-24, at 6:53 PM, Dirk Eddelbuettel wrote:

        
|

        
| > On 24 January 2011 at 15:36, Davor Cubranic wrote:

        
| > | Actually, the interrupt seems to be caught only the first time I enter "foo". When I call it the second time from the prompt, no handler is activated -- I'm not sure why.
| > 
| > Code such as the one shown below was only ever meant to catch one interrupt
| > signal such as Ctrl-C for abort. Upon catching the signal I usually wind the
| > program down.  So I never tried what you are attempting here: to actually be
| > "reentrant" and catch the same signal multiple times.  Let us know how it
| > goes and what you find :)
| 
| Do you mean that this pattern only applies to stand-alone programs?

That was the context in which I used them.  

I'd think one should be able to generalize this but I haven't done that
myself.

Dirk