similar to: 1.8.0 on Unix: interrupting huge print()s ??

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

Hi all, I was hoping to get some advice about a problem that I realize will be difficult to reproduce for some people. I'm running R 1.7.1 on an openMosix (Linux) cluster and have been experiencing some odd slow-downs. If anyone has experience with such a setup (or a similar one) I'd appreciate any help. Here's a simplified version of the problem. I'm trying to run the

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

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

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

OK, I managed to create an example without callr, but it is still somewhat cumbersome. Anyway, here it is. Terminal 1: mkfifo fif R --no-readline --slave --no-save --no-restore < fif Terminal 2: cat > fif Sys.getpid() This will make Terminal 1 print the pid of the R process, so we can send a SIGINT: Terminal 3: kill -INT pid The R process is of course still running happily. Terminal 2

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

On Feb 10, 2005, at 7:38 PM, George W. Gilchrist wrote: > Today I was running a graduate level stats lab using R and we > encountered a > major problem while using the current build of the Cocoa GUI: > >> From the GUI: >> system.time(pbinom(80, 1e5, 806/1e6)) > [1] 14.37 4.94 30.29 0.00 0.00 >> > >> From the command line on the same machine: >>

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

Mosix is a cluster operating system that is a set of kernel patches to Linux on i386 machines. It allows processes to migrate to other nodes on the cluster transparently. See www.mosix.org for details. However, my R processes were refusing to migrate. Using strace, and delving into the R code, I found that it was due to a large number of calls to the system setjmp and longjmp routines - the

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

Barry, Would you mind providing the necessary patch for this behavior? Thanks, Greg > -----Original Message----- > From: Barry Rowlingson [mailto:B.Rowlingson@lancaster.ac.uk] > Sent: Monday, November 04, 2002 8:04 AM > To: r-devel@stat.math.ethz.ch > Subject: Re: longjmp - was: seemingly random "nesting of > readline input" > warnings > > > Luke

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

Hi, An R package on which I am working makes a series of very computationally-intensive and complex .C() calls, that I would like to make interruptible. However, calling R_CheckUserInterrupt() causes a non-local exit, so the memory allocated by malloc() is never freed. The way the code is structured, it might not be practical to replace all the malloc() calls with R_alloc() calls. The question

Hi all I'm running lm()/leaps() kind of computations within a loop, and I submitted the entire thing by sourcing a file of R code in interactive mode. I'd like to interrupt the evaluation of this (it's taking way too long) but I am not able to. I'm running R-1.3.0 from an emacs window (ESS-5.0) and I'm on a linux box, (Debian). I tried Control-c Control-c (nothing happens),

Hi all !!! I have got a MOSIX-Cluster and wanted to upgrade to ext3-fs, but that didn't work out. The ext3-fs patch FAILED to patch the MOSIX-kernel and if I tried to apply the ext3- patch before, the MOSIX-patch failed. Can someone help me with that ? Perhaps someone knows of a conclusion for that problem or can tell me where to get a MOSIX-patch for 2.4.15. I would be glad to hear from

Hi everyone, I recently installed R 1.8.1 on some of our machines and noted quickly that the handling of interrupts has changed since version 1.8.0. Are there any plans to reintroduce the old behaviour as a feature when compiling R or even better as a command line option? The problem is that we are extensively calling C functions from R which take quite a large time to finish. With the new

? 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

Stepan, Andreas gave a lot more thought into what you question in your reply. His question was how you can avoid what you where proposing and have proper threading under safe conditions. Having dealt with this before, I think Andreas' write up is pretty much the most complete analysis I have seen. I'd wait for Luke to chime in as the ultimate authority if he gets to it. The