similar to: save() and interrupts

Hello, My problem is that I have an extension in C++ that can be quite time-consuming. I'd like to make it interruptible. The problem is that if I use the recommended R_CheckUserInterrupt() method I have no possibility to cleanup (e.g. free the memory). I've seen an old thread about this, but I wonder if there's a new and definitive answer. I just do not understand why a simple

NEWS for R 1.8.0 has >> USER-VISIBLE CHANGES >> >> <......> >> >> o On Unix-like systems interrupt signals now set a flag that is >> checked periodically rather than calling longjmp from the >> signal handler. This is analogous to the behavior on Windows. >> This reduces responsiveness to interrupts but prevents bugs

Hello, I am writing an R interface for one of my C++ programs. The computations in C++ are very time consuming (several hours), so the user needs to be able to interrupt them. Currently, the only way I found to do so is calling R_CheckUserInterrupt() frequently. Unfortunately, there are several problems with that: 1. Calling R_CheckUserInterrupt() interrupts immediately, so I have no

Thank you for the feedback and confirmations. Interesting to see that it's also reproducible on macOS expect for Spencer; that might indicate a difference in builds. BTW, my original post suggested that timeout error was for sure detected while running Sys.sleep(10). However, it could of course also be that it is only detected after it finishes. For troubleshooting, the

? Sat, 29 Apr 2023 00:00:02 +0000 Dario Strbenac via R-devel <r-devel at r-project.org> ?????: > Could save.image() be redesigned so that it promptly responds to > Ctrl+C? It prevents the command line from being used for a number of > hours if the contents of the workspace are large. This is ultimately caused by serialize() being non-interruptible. A relatively simple way to hang

With tryCatch() it is possible to catch interrupts with tryCatch(). Then you can use a 'finally' statement to clean up, release resources etc. However, how can I "protect" against additional interrupts? This is a concern when the hold down Ctrl+C and generates a sequence of interrupts. Example: tryCatch({ cat("Press Ctrl+C...\n"); Sys.sleep(5); }, interrupt =

Hi, As was discussed earlier in another thread and as documented in R-exts .Call() should not be interruptible by Ctrl-C. However the following code, which spends most of its time inside mkChar, turned out to be interruptible on RH-7.3 R-1.8.1 gcc-2.96: #include <Rinternals.h> #include <R.h> SEXP foo0(const SEXP nSexp) { int i, n; SEXP resSexp; if (!isInteger(nSexp))

Hello, Could save.image() be redesigned so that it promptly responds to Ctrl+C? It prevents the command line from being used for a number of hours if the contents of the workspace are large. -------------------------------------- Dario Strbenac University of Sydney Camperdown NSW 2050 Australia

On unix, unless event polling is enabled Sys.sleep just waits in a select() call (with a SIGINT handler in place) so the elapsed time isn't checked until after the select call is complete. Rstudio uses event polling, and in particular sets R_wait_usec to 10000, which means event and interrupt checks happen during a Sys.seep call. The R GUI on macOS doesn't seem to do this (but my lldb

Hi. Using Rterm v2.2.1 on WinXP, is there a way to interrupt a call like repeat { readline() } without killing the Command window? Ctrl+C is not interrupting the loop: R : Copyright 2006, The R Foundation for Statistical Computing Version 2.2.1 Patched (2006-01-01 r36947) <snip></snip> > repeat { readline() } ^C ^C ^C ^C On Unix it works. The problem seems to get the

Dear R-devel, Some time ago I started a thread that boiled down to clean-up actions after non-local exits in R, see below. I wonder if there has been any progress on this? R-ext 2.6.1 doesn't say much on the subject. How, for example, do people deal with a situation where their C (C++) function opens a file and then receives a signal or longjump-s on error(), how do they make sure the

On Mon, 31 Oct 2016, Henrik Bengtsson wrote: > Thank you for looking into this Luke. > > On Thu, Oct 27, 2016 at 9:26 AM, <luke-tierney at uiowa.edu> wrote: >> On unix, unless event polling is enabled Sys.sleep just waits in a >> select() call (with a SIGINT handler in place) so the elapsed time >> isn't checked until after the select call is complete.

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

I have a continuous loop running in an external library that I am calling from C (R API). This loop is processing events in real time with the possibility of significant lag between events. When processing an event, I can make use of R_CheckUserInterrupt, but while the external library code is waiting on a new event, I don't have an opportunity to call this - my entry points are only on

Hi r-user, I am trying to save same objects in workspace, but the next error message is show in line command, save(area,cent,larg,mran,eddy,dia,vort,slan,file="stat.Rdata") Erro en save.default(area, cent, larg, mran, eddy, dia, vort, slan, file = "stat.Rdata") : 5 arguments passed to 'saveToConn' which requires 6 Is there a way to help me solve this

setTimeLimit(elapsed=1) causes a timeout error whenever a call takes more than one second. For instance, this is how it works on Windows (R 3.3.1): > setTimeLimit(elapsed=1) > Sys.sleep(10); message("done") Error in Sys.sleep(10) : reached elapsed time limit Also, the error propagates immediately and causes an interrupt after ~1 second; > system.time({ Sys.sleep(10);

Unfortunately --interactive also makes the session interactive(), which is bad for me, as it is a background session. In general, I don't want the interactive behavior, but was wondering if I could send as SIGINT to try to interrupt the computation of the background process, and if that does not work, then I would send a SIGKILL and start up another process. It all works nicely, except for

Hi All, I realize that this is not a really nice reprex, but anyone has an idea why a background R session would "remember" an interrupt (SIGINT) on Unix? rs <- callr::r_session$new() rs$interrupt() # just sends a SIGINT #> [1] TRUE rs$run(function() 1+1) #> Error: interrupt rs$run(function() 1+1) #> [1] 2 It seems that the main loop somehow stores the SIGINT it

Hi, As the subject suggests, I am looking for the most robust way to call an (arbitrary) function from the R API from another but the main POSIX thread in a package's code. I know that, "[c]alling any of the R API from threaded code is ?for experts only? and strongly discouraged. Many functions in the R API modify internal R data structures and might corrupt these data structures if

Yeah, I get that they are async. What happens is that the background process is not doing anything when the process gets a SIGINT. I.e. the background process is just listening on its standard input. AFAICT for an interactive process such a SIGINT is just swallowed, with a newline outputted to the terminal. But apparently, for this background process, it is not swallowed, and it is triggered