Thank you. This gives hope, I am looking forward to the next major release.
May I make a wish that the future try/finally mechanism will inlcude support for C++ exceptions? For example by allowing the programmer to set an error handler that raises a C++ exception. It should be easy in error(), but might be a problem in interrupt handlers (I am not an expert though). Thanks, Vadim > -----Original Message----- > From: Luke Tierney [mailto:[EMAIL PROTECTED] > Sent: Monday, June 14, 2004 7:46 PM > To: Vadim Ogranovich > Cc: R-Help > Subject: RE: [R] mkChar can be interrupted > > On Mon, 14 Jun 2004, Vadim Ogranovich wrote: > > > 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 > > C++ 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. > > Interrupts are not the issue. The issue is making sure that > cleanup actions occur even if there is a non-local exit. A > solution that addresses that issue will work for any > non-local exit, whether it comes from an interrupt or an > exception. So you don't have to put up with anything if you > approach this the right way, > > Currently there is no user accessible C level try/finally > mechanism for insuring that cleanup code is executed during a > non-local exit. > We should make such a mechanicm available; maybe one will > make it into the next major release. > > For now you have two choices: > > You can create an R level object and attach a finalizer > to the object > that will arrange for the GC to close the file at some > point in the > future if a non-local exit occurs. Search > developer.r-project.org for > finalization and weak references for some info on this. > > One other option is to use the R_ToplevelExec function. > This has some > drawbacks since it effectively makes invisible all other error > handlers, but it is an option. It is also not officially > documented > and subject to change. > > > 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? > > R_alloc is stack-based; the stack is unwound on a non-local > exit, so this is released on regular exits and non-local > ones. It uses R allocation, so it could itself cause a > non-local exit. > > Calloc is like calloc but will never return NULL. If the > allocation fails, then an error is signaled, which will > result in a non-local exit. If the allocation succeeds, you > are responsable for calling Free. > > luke > > > > -----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 > > > > -- > 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
