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 again: tryCatch(Sys.sleep(10), interrupt = function(e) e) and then Terminal 1 prints the interrupt condition: <interrupt: > This is macOS and 3.5.3, although I don't think it matters much. Thanks much! G. On Tue, Apr 30, 2019 at 9:50 PM Simon Urbanek <simon.urba...@r-project.org> wrote: > > 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 PM, Gábor Csárdi <csardi.ga...@gmail.com> wrote: > > > > 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 later. FWIW it does not happen on Windows, not very > > surprisingly. > > > > Gabor > > > > On Tue, Apr 30, 2019 at 9:13 PM Simon Urbanek > > <simon.urba...@r-project.org> wrote: > >> > >> 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 > >> evaluation. > >> > >> Cheers, > >> Simon > >> > >> > >>> On Apr 30, 2019, at 3:44 PM, Gábor Csárdi <csardi.ga...@gmail.com> wrote: > >>> > >>> 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 receives > >>> while it is waiting on stdin, and then it triggers it when some input > >>> comes in.... Maybe. Just speculating.... > >>> > >>> Thanks, > >>> Gabor > >>> > >>> ______________________________________________ > >>> R-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>> > >> > > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
