From c@@rd|@g@bor @end|ng |rom gm@||@com  Tue Apr 30 23:09:51 2019
From: c@@rd|@g@bor @end|ng |rom gm@||@com (=?UTF-8?B?R8OhYm9yIENzw6FyZGk=?=)
Date: Tue, 30 Apr 2019 22:09:51 +0100
Subject: [Rd] Background R session on Unix and SIGINT
In-Reply-To: <EDAD9282-9026-4B88-A1A3-B2A63A6ADC3E@R-project.org>
References: <CABtg=Km=Bj_gDr3jsYSvQf479eJhPunRYyU8UQEfaV-YtKvqqQ@mail.gmail.com>
 <3A2C4184-FD39-410A-8392-28C473AAC8D0@R-project.org>
 <CABtg=KkfXU4+7F=Yr2=v=ssg=-naEkYDGM_A6j7UGNWSkjVoTw@mail.gmail.com>
 <EDAD9282-9026-4B88-A1A3-B2A63A6ADC3E@R-project.org>
Message-ID: <CABtg=Knor462S640xB8bAZbMG+TAq7hur14gaBTt4aUiP5mXoQ@mail.gmail.com>

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



[Rd] Background R session on Unix and SIGINT
=?UTF-8?B?R8OhYm9yIENzw6FyZGk=?=