Capturing signals from within external libs
Simon,
Very likely butchered my initial problem explanation. The issue is that I
make a call to a library, something like:
SEXP my_fun() {
...
CB = MyCallback("XYZ"); /* this contains callback functions that in turn
use R */
externalLibCall(CB); /* infinite loop that won't return as it is
capturing streaming data */
/* we never get here */
Return(R_NilValue);
}
My callbacks look something like
on_event_A () {
R_CheckUserInterrupt():
evalRFunctionFromC();
}
But event_A only gets called when a new message arrives. When a new
message arrives the on_event_A gets called from within the external
library code (hence calling R), but only when a message arrives.
At this point R_CheckUserInterrupt() works just fine. The problem is when
the external process is waiting on a new message. I have no entry to
check whether or not a message is available, nothing akin to select().
Basically I only get control in my callback when a new message happens.
So if there is no new message (in the context above it is a message/tick
from an exchange), the process spins/waits/not too sure what happens
internally, but the net result is I don't see anything. I am waiting. It
is at this point that I want to force an interrupt.
My current solution is just to redefine as my SIGINT handler before the
externalLibCall call, with an ungraceful exit() internal to it. Dirty,
but lets me break. In the ideal world I would be returned to the R prompt,
but it isn't overly critical in this application since it is being run
more or less headless as is.
The other problem, which makes me cringe of course, is that this is all
further complicated by the fact that it is not just C, but C++ and running
on Win64 ;-) I tried not to mention that of course ...
Your insights are very appreciated, and I now have further knowledge into
making this work in other applications, but my hope for this one is
dwindling.
Best,
Jeff
On 5/23/12 11:49 AM, "Simon Urbanek" <simon.urbanek at r-project.org> wrote:
On May 23, 2012, at 12:40 PM, Jeffrey Ryan wrote:
Simon, Thanks for the clarifying example. I fear my current set up fails the test for 'no R calls',
Well, but in that case you already have interrupt points so I'm not sure what is the problem? I thought the whole point is that you have long processing in some 3rd party library where you can't call R API so that's why you need the hack in the first place ...
so I think I am stuck on the ugly variant for my current challenge, but I will be able to use this in other places. Thanks again, Jeff On 5/22/12 4:45 PM, "Simon Urbanek" <simon.urbanek at r-project.org> wrote:
Jeff, On May 22, 2012, at 4:31 PM, Jeffrey Ryan wrote:
I have a continuous loop running in an external library that I am calling from C (R API). This loop is processing events in real time with the possibility of significant lag between events. When processing an event, I can make use of R_CheckUserInterrupt, but while the external library code is waiting on a new event, I don't have an opportunity to call this - my entry points are only on events.
Assuming that while in the library there are no R calls (important!),
you
can use setjmp/longjmp to branch your code depending on whether you
raise
an interrupt or not (see below). This also makes sure that you process
things on the R side properly
Another alternative is to run your library call on a separate thread
and
have R wait for the result. In that case you don't need to mess with
interrupts since your library code will run separately from R. The
downside is that you need to mess with threads which may or may not be
an
issue depending on the complexity of your code and whether you want it
to
be cross-platform or not.
Cheers,
Simon
Example code:
#include <signal.h>
#include <setjmp.h>
#include <unistd.h>
#include <Rinternals.h>
#include <R_ext/GraphicsEngine.h> /* only needed if you use
R_interrupts_pending */
static jmp_buf jenv;
static void my_int(int sig) {
longjmp(jenv, 1); /* this also restores the interrupt handlers */
}
SEXP my_R_function(...) {
if (setjmp(jenv) == 0) { /* enter your protected code */
void (*old_sig)(int);
old_sig = signal(SIGINT, my_int);
/* call your library here */
/* restore original INT handler */
signal(SIGINT, old_sig);
} else { /* this will get called on interrupt */
/* you can do what you want - you're back to R-safe code here, so you
can either raise an error or return from your function */
/* if you want to trigger regular R interrupt handling, use this: */
R_interrupts_pending = 1;
R_CheckUserInterrupt();
/* the above should not return */
}
I can capture a SIGINT by redefining signal(SIGINT, myhandler) before
calling the lib, but I am somewhat at a loss in terms of what I can do
within the handler that would let me pass control back to R.
void myhandler (int s) {
error("interrupt caught!");
}
Works, but I am sure it isn't supposed to. In fact I know it is
wrong,
since after interrupting once SIGINTs are subsequently ignored, even
if
I
reset the signal to the original one (as returned by the first call to
signal).
Currently I can exit(1) of course, but that is tragically bad form
IMO,
though will work in my situation.
In short, what is the proper way to handle SIGINT in external code
that
is
called from R, that allows R to handle the signal. Thoughts or
suggestions appreciated.
Thanks,
Jeff
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel