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.urbanek at 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.gabor at 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 at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > >
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.gabor at 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.urbanek at 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.gabor at 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 at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> >
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.urbanek at 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.gabor at 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.urbanek at 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.gabor at 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 at r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>> > >> > > >