[R] mkChar can be interrupted
Vadim Ogranovich
vograno at evafunds.com
Tue Jun 15 00:21:31 CEST 2004
> -----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?
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.
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'?
Thanks,
Vadim
>
> 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
>
>
>
More information about the R-help
mailing list