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). > > 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: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel