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
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
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
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
Hi Peter
Yes, that looks roughly right to me. I would be in favour of your
option (b), partly because it is probably easiest and partly because
that retains the basic graphics device startup logic pattern that is
replicated across all(?) graphics devices.
Paul
On 28/04/19 11:39 AM, peter d
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
A Simon pointed out the interrupt is recorded but not processed until
a safe point.
When reading from a fifo or pipe R runs non-interactive, which means
is sits in a read() system call and the interrupt isn't seen until
sometime during evaluation when a safe checkpoint is reached.
When reading fr
Dear All,
I'm running into issues with calling mccollect on a list containing NULL
using R 3.6 (this used to work in 3.5.3):
jobs <- lapply(
list(NULL, 'foobar'),
function(x) mcparallel(identity(x)))
mccollect(jobs, wait = FALSE, timeout = 0)
#> Error in names(res) <- pnames[match(s, pids
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 w
