On Apr 26, 2011, at 7:30 AM, schattenpfla...@arcor.de wrote:
> I have tested the solutions suggested by Simon and Thomas on a Linux machine.
> These are my findings:
>
>> On Windows you can look at the variable "UserBreak", available from
>> Rembedded.h. Outside of Windows, you can look at R_interrupts_pending,
>> available from R_ext/GraphicsDevice.h. R_ext/GraphicsDevice.h also has
>> R_interrupts_suspended, which you may or may not want to take into account,
>> depending on your use-case.
> I did not manage to get this to work. Neither R_interrupts_pending nor
> R_interrupts_suspended seem to change when I press ctrl+c. Perhaps this is
> due to the fact that I run R in a terminal without any graphical interface?
>
Thomas' suggestion was not aimed at your problem - it was sort of the inverse
(more at your Qt question). If you want to interrupt R you can mess with those
flags and them let R run the event loop. It doesn't work in your (original)
case.
>> static void chkIntFn(void *dummy) {
>> R_CheckUserInterrupt();
>> }
>> // this will call the above in a top-level context so it won't longjmp-out
>> of your context
>> bool checkInterrupt() {
>> return (R_ToplevelExec(chkIntFn, NULL) == FALSE);
>> }
>> // your code somewhere ...
>> if (checkInterrupt()) { // user interrupted ... }
> This solution works perfectly! It takes slightly longer to call this function
> than the plan R_CheckUserInterrupt() call, but in any reasonable scenario,
> the additional time is absolutely insignificant.
>
> Inside OpenMP parallel for constructs, one has to make sure that only the
> thread satisfying omp_get_thread_num()==0 makes the call (the 'master'
> construct cannot be nested inside a loop). I can then set a flag, which is
> queried by every thread in every loop cycle, causing fast termination of the
> parallel loop. After the loop, I throw an exception. Thus, my code is
> terminated gracefully with minimal effort. I can do additional cleanup
> operations (which usually is not necessary, since I use smart pointers), and
> report details on the interrupt to the user.
>
> With my limited testing, so far I have not noticed any downsides. Of course,
> there is the obvious drawback of not being supported officially (and thus
> maybe being subject to change),
Actually, it is in the official API (Rinternals.h) so I don't think that is the
issue.
> the question of portability, and the question of interoperability with other
> errors.
>
It is portable as well, so I'd say the main concern is what happens when events
trigger something that is not related to you and you eat those errors. They
will act as user-interrupt to you even if it's not what the user intended. One
could argue that it's the lesser of the evils, because if you don't do anything
R will just block so those events would have to wait until you're done anyway.
> Moreover, I have found an old thread discussing almost the same topic:
> http://tolstoy.newcastle.edu.au/R/e4/devel/08/05/1686.html .
> The thread was created in 2008, so the issue is not really a new one. The
> solution proposed there is actually the same as the one suggested by Simon,
> namely using R_ToplevelExec().
>
Interesting - I'm glad Luke also suggested C-level onexit bac then - it is
something I was thinking about before ..
Cheers,
Simon
> An officially supported, portable solution would of course be much
> appreciated!
>
>
> Best regards,
> Peter
>
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
