This is disappointing. How on Earth can mkChar know when it is safe or not to make a long jump? For example if I just opened a file how am I supposed to close it after the long jump? I am not even talking about C++ where long jumps are simply devastating... (and this is the language I am coding in :-( )
Ok. A practical question: is it possible to somehow block R_CheckUserInterrupt? I am ready to put up with out-of-memory errors, but Ctrl-C is too common to be ignored. And I think it makes relevant again the question I asked in another related thread: how is memory allocated by Calloc() and R_alloc() stand up against long jumps? Thanks, Vadim > -----Original Message----- > From: Luke Tierney [mailto:[EMAIL PROTECTED] > Sent: Monday, June 14, 2004 5:43 PM > To: Vadim Ogranovich > Cc: R-Help > Subject: RE: [R] mkChar can be interrupted > > On Mon, 14 Jun 2004, Vadim Ogranovich wrote: > > > I am confused. Here is an excerpt from R-exts: > > > > "As from R 1.8.0 no port of R can be interrupted whilst > running long > > computations in compiled code,..." > > > > Doesn't it imply that the primitive functions like allocVector, > > mkChar, etc., which are likely to occur in any compiled code called > > via .Call, are not supposed to handle interrupts in any way? > > No it does not. Read the full context. It says that if you > wite a piece of C code that may run a long time and you want > to guarantee that users will be able to interrupt your code > then you should insure that R_CheckUserInterrupt is called > periodically. If your code already periodically calls other > R code that checks for interrupts then you may not need to do > this yourself, but in general you do. > > Prior to 1.8.0 on Unix-like systems the asynchronous signal > handler for SIGINT would longjmp to the nearest top level or > browser context, which meant that on these sytems any code > was interruptible at any point unless it was explicitly > protected by a construct that suspended interrupts. Allowing > interrupts at any point meant that inopportune interrupts > could and did crash R, which is why this was changed. > > Unless there is explicit documentation to the contrary you > should assume that every function in the R API might allocate > and might cause a non-local exit (i.e. a longjmp) when an > exception is raised (and an interrupt is one of, but only one > of, the exceptions that might occur). > > luke > > > Thanks, > > Vadim > > > > > > > From: Luke Tierney [mailto:[EMAIL PROTECTED] > > > > > > On Mon, 14 Jun 2004, Vadim Ogranovich wrote: > > > > > > > > From: Luke Tierney [mailto:[EMAIL PROTECTED] > > ... > > > > > > > > > > Not sure why you think this suggest mkChar can be interrupted. > > > > > > > ... > > > > > 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. > > > > These are not relevant since Ctrl-C is pressed when the > code is inside > > for (i=0; i<n; ++i) { > > SET_STRING_ELT(resSexp, i, mkChar("foo")); > > } > > > > Just look at the way I deliver the signal. > > > > ______________________________________________ > > [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu > > > ______________________________________________ [EMAIL PROTECTED] 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