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 SIG
Can you give an example without callr? The key is how is the process stated and
what it is doing which is entirely opaque in callr.
Windows doesn't have signals, so the process there is entirely different. Most
of the WIN32 processing is event-based.
Cheers,
Simon
> On Apr 30, 2019, at 4:17 P
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 th
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 eva
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
