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 <[EMAIL PROTECTED]> 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. 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 >>> >>> >> >> > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
