[R] mkChar can be interrupted
Luke Tierney
luke at stat.uiowa.edu
Tue Jun 15 01:03:18 CEST 2004
On Mon, 14 Jun 2004, Vadim Ogranovich wrote:
> > -----Original Message-----
> > From: Luke Tierney [mailto:luke at stat.uiowa.edu]
> > Sent: Monday, June 14, 2004 1:30 PM
> > To: Vadim Ogranovich
> > Cc: R-Help
> > Subject: Re: [R] mkChar can be interrupted
> >
> > Not sure why you think this suggest mkChar can be interrupted.
> >
> > If you want to figure out how interrupt handling works on
> > unix, run under gdb and single step from the signal to the
> > next point where R_CheckUserInterrupt is called. You should
> > find that the signal handler sets a flag and that flag is
> > checked at various safe points by calls to this function. I
> > don't believe there are any such safe points in mkChar, but
> > there are several potential ones within your example.
>
> Apart from mkChar I am only calling SET_STRING_ELT. Is this what you
> mean?
You are printing, you have an assignment expression, all of those
contain points where an interrupt could be checked for.
> To make sure, I am not trying to enable or handle interrupts. On the
> contrary, I want them to be disabled for the duration of .Call, which is
> what I thought R was supposed to do for me. I am surprised it didn't.
>
> As to why I singled out mkChar, well, strictly speaking it is
> 'SET_STRING_ELT(resSexp, i, mkChar("foo"))' where the interrupt somehow
> goes through. But SET_STRING_ELT is much faster than mkChar so I guessed
> that it must be mkChar.
> Anyway, be it SET_STRING_ELT or mkChar, the interrupt should have been
> blocked.
Not sure why you are guessing since you can find out for sure using gdb.
Looking at the current definition of the END_SUSPEND_INTERRUPTS macro
it seems that on systems where user interrupt uses signals a pending
interrupt will be handled at the end of a GC by calling onintr. So on
unix systems mkChar would contain a safe point. This may be where the
interrupt is handled in your case. If you want to you can confirm
this by setting a gdb breakpoint in onintr (or perhaps Rf_onintr).
(We should probably add a way of checking of user interrupts here on
non-unix systems too, though care is needed on performance.)
> As an additional check I tried to interrupt right before and right after
> for (i=0; i<n; ++i) {
> SET_STRING_ELT(resSexp, i, mkChar("foo"));
> }
> but the interrupt was rightfully blocked.
>
>
> I understand that .Call blocks interrupts, but it seems that very
> primitive functions like SET_STRING_ELT, mkChar can decide to handle
> them. This is surprising and I think my conjecture is wrong, but how
> else to explain that I was able to interrupt 'foo0'?
At this point it looks like nothing other than GC and some graphics
code actually blocks interrupts. Whether any ot these are still
necessary given that we no longer longjmp oout of the signal handler
is not clear. Interrputs are checked for at places where it is safe to
do a non-local exit, which on unix systems includes at the end of a
GC. Any C code that uses R allocation has to be robust to non-local
exits out of allocation calls since out of memory situations will also
cause a non-local exit. Similarly any C code that calls into the R
API has to be robust to non-local exits if the internal code can
generate an error, and for this purpose a user interrupt is analogous
to any other error.
Best,
luke
> > As mentioned in a reply in another thread, interrupt handling
> > is one aspect of R internals that is still evolving. Among
> > other things, we will need to make changes as we improve
> > support for other event loops.
> > [In applications with graphical interfaces signals are not
> > the right way to deal with user interruption (in particular
> > on operating systems that don't support proper signals)].
> >
> > Best,
> >
> > luke
> >
> > On Mon, 14 Jun 2004, Vadim Ogranovich wrote:
> >
> > > Hi,
> > >
> > > As was discussed earlier in another thread and as
> > documented in R-exts
> > > .Call() should not be interruptible by Ctrl-C. However the
> > following
> > > code, which spends most of its time inside mkChar, turned out to be
> > > interruptible on RH-7.3 R-1.8.1 gcc-2.96:
> > >
> > >
> > > #include <Rinternals.h>
> > > #include <R.h>
> > >
> > > SEXP foo0(const SEXP nSexp) {
> > > int i, n;
> > > SEXP resSexp;
> > >
> > > if (!isInteger(nSexp))
> > > error("wrong arg type\n");
> > >
> > > n = asInteger(nSexp);
> > > resSexp = PROTECT(allocVector(STRSXP, n));
> > >
> > > Rprintf("!!!time to interrup!!!\n");
> > > for (i=0; i<n; ++i) {
> > > SET_STRING_ELT(resSexp, i, mkChar("foo"));
> > > }
> > >
> > > Rprintf("end mkChar\n");
> > > UNPROTECT(1);
> > >
> > > return R_NilValue;
> > > }
> > >
> > >
> > >
> > > # invoke 'foo0' and give it an argument large enough to let
> > you type
> > > Ctrl-C # double the argument if you see "end mkChar" and do
> > it again
> > > :-)
> > > > x <- .Call("foo0", as.integer(1e7))
> > > !!!time to interrup!!!
> > >
> > > >
> > > > version
> > > _
> > > platform i686-pc-linux-gnu
> > > arch i686
> > > os linux-gnu
> > > system i686, linux-gnu
> > > status
> > > major 1
> > > minor 8.1
> > > year 2003
> > > month 11
> > > day 21
> > > language R
> > >
> > >
> > > Thanks,
> > > Vadim
> > >
> > > ______________________________________________
> > > R-help at stat.math.ethz.ch mailing list
> > > https://www.stat.math.ethz.ch/mailman/listinfo/r-help
> > > PLEASE do read the posting guide!
> > > http://www.R-project.org/posting-guide.html
> > >
> >
> > --
> > Luke Tierney
> > 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
> >
> >
> >
>
>
--
Luke Tierney
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
More information about the R-help
mailing list