From @|mon@urb@nek @end|ng |rom R-project@org  Tue Apr 30 22:13:43 2019
From: @|mon@urb@nek @end|ng |rom R-project@org (Simon Urbanek)
Date: Tue, 30 Apr 2019 16:13:43 -0400
Subject: [Rd] Background R session on Unix and SIGINT
In-Reply-To: <CABtg=Km=Bj_gDr3jsYSvQf479eJhPunRYyU8UQEfaV-YtKvqqQ@mail.gmail.com>
References: <CABtg=Km=Bj_gDr3jsYSvQf479eJhPunRYyU8UQEfaV-YtKvqqQ@mail.gmail.com>
Message-ID: <3A2C4184-FD39-410A-8392-28C473AAC8D0@R-project.org>

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
> 



[Rd] Background R session on Unix and SIGINT
Simon Urbanek