search for: r_checkuserinterrupt

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 possibility to exit my code gracefully. In particular, I suppose that objects created on the heap (e.g., STL containers) are not destructed properly. 2. Ca...

...rmance. It seems as if this only occurs > for > certain arguments, but we saw this on ~15 different machines today. > And it > seems to only be when running the Cocoa GUI. No problems at all with > this > under Windoze. Any ideas? The cause is pbeta_raw calling (indirectly via R_CheckUserInterrupt) R_ProcessEvents for every iteration - and for small p the number of iterations goes really high (e.g. for the case above n=99919). R_ProcessEvents is not a cheap operation, because it enters system event loop and processes any pending events. A quick fix could be the following patch, which ch...

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 R_CheckUserInterrupt() like method returning a boolean could not be used. Please enlighten me !...

...mately caused by serialize() being non-interruptible. A relatively simple way to hang an R session for a long-ish time would therefore be: f <- xzfile(nullfile(), 'a+b') x <- rep(0, 1e9) # approx. 8 gigabytes, adjust for your RAM size serialize(x, f) close(f) This means that calling R_CheckUserInterrupt() between saving individual objects is not enough: R also needs to check for interrupts while saving sufficiently long vectors. Since the serialize() infrastructure is carefully written to avoid resource leaks on allocation failures, it looks relatively safe to liberally sprinkle R_CheckUserInterr...

...ed later. FWIW it does not happen on Windows, not very surprisingly. Gabor On Tue, Apr 30, 2019 at 9:13 PM Simon Urbanek <simon.urbanek at r-project.org> wrote: > > Interrupts are not synchronous in R - the signal only flags the request for interruption. Nothing actually happens until R_CheckUserInterrupt() is called at an interruptible point. In you case your code is apparently not calling R_CheckUserInterrupt() until later as a side-effect of the next evaluation. > > Cheers, > Simon > > > > On Apr 30, 2019, at 3:44 PM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote: >...

...t;> > >>> On Tue, Apr 30, 2019 at 9:13 PM Simon Urbanek > >>> <simon.urbanek at r-project.org> wrote: > >>>> > >>>> Interrupts are not synchronous in R - the signal only flags the request for interruption. Nothing actually happens until R_CheckUserInterrupt() is called at an interruptible point. In you case your code is apparently not calling R_CheckUserInterrupt() until later as a side-effect of the next evaluation. > >>>> > >>>> Cheers, > >>>> Simon > >>>> > >>>> > >&gt...

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

...uadcore. Besides, due to security reasons, a hash of the library file is going to be computed. Still do not know how long it will take. Questions. Is 1 second acceptable for R? Slower machines may take a lot longer to return from R_init_XXXXX(). Does R_init_XXXXX() have to return soon or call R_CheckUserInterrupt()? Or is it somehow free from this R need? Is it safe to load the second library and compute the hash within other threads so R_init_XXXXX goes on? If some function of my extension library is called it can call R_CheckUserInterrupt() if and while the threads do not end. If such use of threads...

With ?if?(!j--)?{ ?????R_CheckUserInterrupt(); ?????j?=?10000; ?} as?in?current?R?devel?(r83976),?j goes negative (-1) and interrupt is checked every 10001 instead of 10000. I?prefer ?if?(!--j)?{ ?????R_CheckUserInterrupt(); ?????j?=?10000; ?} . In?current?R?devel?(r83976),?if?EOF?is?reached,?the?outer?loop?keeps?going,?i?keeps?incremen...

...will fail to solve the issue? Or might they even cause new problems? d) Are there alternative/better solutions? Any feedback on this is highly appreciated. Below you can find a template which, combines the proposed solutions (and skips all non-illustrative checks of return values). Additionally, R_CheckUserInterrupt() is used in combination with R_UnwindProtect() to regularly check for interrupts from the main thread, while still being able to cleanly cancel the threads before fun_running_in_main_thread() is left via a longjmp. This is e.g. required if the secondary threads use memory which was allocated in fu...

...computation, no question about that. It's just that if you send an interrupt while you're *not* doing any computations, it will be signaled but not raised until the interrupts are checked since there is no one to check it. This goes back to my original response - the interactive REPL calls R_CheckUserInterrupt(), but the straight stdin-prcessing doesn't (since it's expected to be a script, not interactive prompt). If you just want to clear interrupts before next processing you can either just run R_CheckUserInterrupt() explicitly, or on R side do anything that does that, e.g. to take your example...

...y. > > > > Gabor > > > > On Tue, Apr 30, 2019 at 9:13 PM Simon Urbanek > > <simon.urbanek at r-project.org> wrote: > >> > >> Interrupts are not synchronous in R - the signal only flags the request for interruption. Nothing actually happens until R_CheckUserInterrupt() is called at an interruptible point. In you case your code is apparently not calling R_CheckUserInterrupt() until later as a side-effect of the next evaluation. > >> > >> Cheers, > >> Simon > >> > >> > >>> On Apr 30, 2019, at 3:44 PM, G?bor...

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 events. I can capture a SIGINT by redefining signal(SIGINT, myhandler) before calling the lib, but I am somewhat at a loss in terms of what I can do within the...

Hi R developers, On slow file systems with large lists of files, file.exists can take a long time to run. It would be nice if users could interrupt this function. I think it would be simple to add: https://svn.r-project.org/R/trunk/src/main/platform.c, at line 1373, add "R_CheckUserInterrupt();" perhaps every some number of iterations if performance is a concern here. Thanks, Chris ________________________________ This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure)...

...ssue? Or might they even cause new problems? >> d) Are there alternative/better solutions? >> Any feedback on this is highly appreciated. >> Below you can find a template which, combines the proposed solutions (and skips all non-illustrative checks of return values). Additionally, R_CheckUserInterrupt() is used in combination with R_UnwindProtect() to regularly check for interrupts from the main thread, while still being able to cleanly cancel the threads before fun_running_in_main_thread() is left via a longjmp. This is e.g. required if the secondary threads use memory which was allocated in fu...

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))

...issue? Or might they even cause new problems? > d) Are there alternative/better solutions? > > Any feedback on this is highly appreciated. > > Below you can find a template which, combines the proposed solutions (and skips all non-illustrative checks of return values). Additionally, R_CheckUserInterrupt() is used in combination with R_UnwindProtect() to regularly check for interrupts from the main thread, while still being able to cleanly cancel the threads before fun_running_in_main_thread() is left via a longjmp. This is e.g. required if the secondary threads use memory which was allocated in fu...

Interrupts are not synchronous in R - the signal only flags the request for interruption. Nothing actually happens until R_CheckUserInterrupt() is called at an interruptible point. In you case your code is apparently not calling R_CheckUserInterrupt() until later as a side-effect of the next evaluation. Cheers, Simon > On Apr 30, 2019, at 3:44 PM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote: > > Hi All, > > I...

...ndows, not very > surprisingly. > > Gabor > > On Tue, Apr 30, 2019 at 9:13 PM Simon Urbanek > <simon.urbanek at r-project.org> wrote: >> >> Interrupts are not synchronous in R - the signal only flags the request for interruption. Nothing actually happens until R_CheckUserInterrupt() is called at an interruptible point. In you case your code is apparently not calling R_CheckUserInterrupt() until later as a side-effect of the next evaluation. >> >> Cheers, >> Simon >> >> >>> On Apr 30, 2019, at 3:44 PM, G?bor Cs?rdi <csardi.gabor at...

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