[Rd] sending signals to embedded R

[Luke Tierney]

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

> On Sat, 5 May 2007, Luke Tierney wrote:
>
>> 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).
>
> That belief is correct (it has a menu item and a button), but my final 
> parenthetical remark was that gnomeGUI was not wedged into the event loop.
>
>>> 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.
>
> We builtin the ability for a front-end to register handlers with the R event 
> loop, including a polling handler (and that is how we can have a Tcl/Tk front 
> end).  That postdates gnomeGUI, which runs the Gtk event-loop, not R's.
>

I had forgotten about that -- thanks for the reminder.

However, R_PolledEvents is only called from a limited set of places
now (including the socket reading code to keep things responsive
during blocking reads).  But it is not called from the interupt
checking code, which means if a user does something equivalent to

    while (TRUE) {}

there is not point where events get looked at to see a user interrupt
action. The current definition of R_CheckUserInterrupt is

void R_CheckUserInterrupt(void)
{
     R_CheckStack();
     /* This is the point where GUI systems need to do enough event
        processing to determine whether there is a user interrupt event
        pending.  Need to be careful not to do too much event
        processing though: if event handlers written in R are allowed
        to run at this point then we end up with concurrent R
        evaluations and that can cause problems until we have proper
        concurrency support. LT */
#if  ( defined(HAVE_AQUA) || defined(Win32) )
     R_ProcessEvents();
#else
     if (R_interrupts_pending)
         onintr();
#endif /* Win32 */
}

So only on Windows or Mac do we do event processing.  We could add a
R_PolledEvents() call in the #else bit to support this, though the
cautions in the comment do need to be kept in mind.

Best,

luke

> So my assumption 'worked via the R-Unix eventloop' was that a handler 
> (probably a polling handler) had been wedged in the eventloop.
> That was in contrast to running under a separate thread.
>
>> The UI provided by a shell running in a separate process may not have
>> a 'G' but it does have its advantages :-)
>
> Or a separate thread, as Rterm.exe does.  Really RGui should also run in a 
> separate thread, but when Guido did so, it did not work under Windows 95: if 
> we ever give up support for pre-NT Windows I will take a look again at this.
>
> I guess my underlying point is that rather than run the GUI from 
> R_ProcessEvents (as RGui is), on Unix you can run it from an eventloop 
> handler.
>
> Brian
>
>> 
>> 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