[Rd] sending signals to embedded R

[Luke Tierney]

On Sat, 5 May 2007, Prof Brian Ripley wrote:

> On Fri, 4 May 2007, Luke Tierney wrote:
>
>> On Fri, 4 May 2007, Deepayan Sarkar wrote:
>> 
>>> On 5/4/07, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
>>>> On Fri, 4 May 2007, Deepayan Sarkar wrote:
>>>> 
>>>>> one thing I haven't been able to figure out from R-exts is how to
>>>>> interrupt a calculation running inside an embedded R. C code inside R
>>>>> calls R_CheckUserInterrupt() intermittently to check for interrupts,
>>>>> but how does my GUI tell R that the user wants it interrupted?
>>>> 
>>>> Well, the intention is that you send an interrupt, which hardly needs to
>>>> be in the manual.
>>> 
>>> I didn't mean to imply that it does. I'm just new to signals and
>>> things that should be obvious aren't.
>>> 
>>> Basically kill(2) seems to be the right thing to use, but I wasn't
>>> sure what the PID needs to be. Turns out sending SIGINT to my GUI from
>>> a shell interrupts R, so raise(SIGINT) should be enough.
>> 
>> The tricky bit here is figuring out who does the sending.  It you have
>> a separate thread/process for the GUI and R then that is fine (though
>> may raise other issues).  If it is a single thread then you need your
>> event processing to get an occasional look in to recognise the user
>> action that triggers an interrupt. The Windows version handles this by
>> having R_CheckUserInterrupt() do a limited amount of event processing
>> (you need to be careful in GUI events have R actions associated with
>> them).  I believe the Mac version is similar though it has been a
>
> I was assuming that Deepayan's GUI (which seems to need Qt4, BTW, so I was 
> unable to compile it) worked via the R-Unix eventloop, in which case it gets 
> some CPU time from time to time.

I was assuming that as well.  But my recollection is that on unix the
event loop is only run from within the console reader.  On Windows
(and Mac OS X I believe) some event processing also happens in
R_CheckUserInterrupt(); on Windows there is also some more in some
blocking library calls, like socket reads as I recall.  But unless
things have changed since I last looked none of that happens on unix.

>
> gnomeGUI has an interrupt menu item with action 'onintr', which may well be 
> what Deepayan is looking for: the only reason that package still exists is to 
> provide example code.  (Not that it was ever properly integrated with the R 
> event loop.)

It does have some sort of interrupt device (I can't recall if it is a
menu item or a butto and I can't seem to build a working gnomeGUI to
check). And I believe if you try to use that item (or button?) during
a long-running computation you can't because the events won't be
looked at until R gets back to a console read, at which point the
events will be processed and you jump to the top level (where you
already are).

>
> If the issue is what happens when the user Ctrl-C's in the GUI console, that 
> depends on what the GUI toolkit does with keyboard input: if it generates a 
> SIGINT this should just work, but otherwise the keyboard handler needs to be 
> told to call onintr() one way or another.

Again only if the GUI gets a chance to look at the keyboard input,
which I don't think we currently give it.

The UI provided by a shell running in a separate process may not have
a 'G' but it does have its advantages :-)

Best,

luke

>> while since I looked at that. I don't believe the unix version of
>> R_CheckUserInterrupt() does not provide hooks for installing such
>> checking (we have talked about this off an on but I don't believe
>> anything happened -- could be wrong there though).
>> 
>> If Qt allows this one option may be to have events on your nterrupt
>> widget managed by a small thread that does nothing other than send a
>> signal to the main thread if the widget is clicked.
>> 
>> Best,
>> 
>> luke
>> 
>> 
>
>

-- 
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu