similar to: save() and interrupts

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

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

On 12/18/24 01:19, Simon Urbanek wrote: > It seems benign, but has implications since checking time is actually not a cheap operation: adding jus ta time check alone incurs a penalty of ca. 700% compared with the time it takes to call R_CheckUserInterrupt(). Generally, it makes no sense to check interrupts at every iteration - you'll find code like if (++i % 10000 == 0)

It seems benign, but has implications since checking time is actually not a cheap operation: adding jus ta time check alone incurs a penalty of ca. 700% compared with the time it takes to call R_CheckUserInterrupt(). Generally, it makes no sense to check interrupts at every iteration - you'll find code like if (++i % 10000 == 0) R_CheckUserInterrupt(); in loops to make sure it's not called

This seems like a great idea. Would it help to escalate this to a post on R-bugzilla, so it is less likely to fall through the cracks? On 12/17/24 09:51, Jeroen Ooms wrote: > A more generic solution would be for R to throttle calls to > R_CheckUserInterrupt(), because it makes no sense to check 1000 times > per second if a user has interrupted, but it is difficult for the > caller to

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

A more generic solution would be for R to throttle calls to R_CheckUserInterrupt(), because it makes no sense to check 1000 times per second if a user has interrupted, but it is difficult for the caller to know when R_CheckUserInterrupt() has been last called, or do it regularly without over-doing it. Here is a simple patch: https://github.com/r-devel/r-svn/pull/125 See also:

In help("pskill", package = "tools") is says: Only SIGINT and SIGTERM will be defined on Windows, and pskill will always use the Windows system call TerminateProcess. As far as I understand it, TerminateProcess [1] terminates the process "quite abruptly". Specifically, it is not possible for the process to intercept the termination and gracefully shutdown. In R

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

tl;dr: R_CheckUserInterrupt() can be a performance bottleneck within GUIs. This also affects functions in the 'stats' package, which could be improved by changing the position of calls to R_CheckUserInterrupt(). Dear all, Recently I was puzzled because some code in a package under development, which consisted almost entirely of a .Call() to a function written in

I think for reliability and portability of termination, one needs to implement an application-specific termination protocol on both ends. Only within specific application constraints, one can also define what graceful termination means. Typically, one also has other expectations from the termination process - such that the processes will terminate in some finite time/soon. In some cases one

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