similar to: sending signals to embedded R

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

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

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

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

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

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

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

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

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:

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

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

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.

Your analysis looks pretty complete to me and your solutions seems plausible. That said, I don't know that I would have the level of confidence yet that we haven't missed an important point that I would want before going down this route. Losing stack checking is risky; it might be eventually possible to provide some support for this to be handled via a thread-local variable. Ensuring

Hi, I was wondering if anybody knew how to trap SIGINTs (ie Ctrl-C) in backend C++ code for R extensions? I'm writing a package that uses the GPU for some hefty matrix operations in a tightly coupled parallel algorithm implemented in CUDA. The problem is that once running, the C++ module cannot apparently be interrupted by a SIGINT, leaving the user sat waiting even if they realise

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

I am using RGtk2 for a simple GUI (rattle). I start rattle from the RGui and I remain able to interact with the RGui while rattle runs. Under MS/Windows, when rattle has initiated some other underlying R command the rattle GUI remains responsive (unlike under GNU/Linux where it is not responsive until the underlying command completes). I can interrupt the running command with a press of the Esc

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