R devel - Apr 2019 - Background R session on Unix and SIGINT

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

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
>

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