On 14/04/2008 4:33 PM, Vadim Organovich wrote:> Dear R-devel,
>
>
>
> Some time ago I started a thread that boiled down to clean-up actions after
non-local exits in R, see below. I wonder if there has been any progress on
this? R-ext 2.6.1 doesn't say much on the subject.
>
>
>
> How, for example, do people deal with a situation where their C (C++)
function opens a file and then receives a signal or longjump-s on error(), how
do they make sure the file is eventually closed?
The finalizer code that Luke mentioned is more easily accessible now
than it was in 2004. See the section on external pointers and weak
references in the Writing R Extensions manual.
The idea would be to create an external pointer object that controls the
resource. If there's an error, at the next GC the external pointer will
be finalized and that's where the cleanup can happen.
Duncan Murdoch
>
>
> Thanks,
>
> Vadim
>
>
>
> 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
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:luke at stat.uiowa.edu<mailto:luke at
stat.uiowa.edu?Subject=RE:%20%5BR%5D%20mkChar%20can%20be%20interrupted>]
>>> 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:luke at
stat.uiowa.edu<mailto:luke at
stat.uiowa.edu?Subject=RE:%20%5BR%5D%20mkChar%20can%20be%20interrupted>]
>>>>>
>>>>> On Mon, 14 Jun 2004, Vadim Ogranovich wrote:
>>>>>
>>>>>>> From: Luke Tierney [mailto:luke at
stat.uiowa.edu<mailto:luke at
stat.uiowa.edu?Subject=RE:%20%5BR%5D%20mkChar%20can%20be%20interrupted>]
>>>> ...
>>>>>>> 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.
>>>>
>>>> ______________________________________________
>>>> R-help at stat.math.ethz.ch<mailto:R-help at
stat.math.ethz.ch?Subject=RE:%20%5BR%5D%20mkChar%20can%20be%20interrupted>
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<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<mailto:luke at
stat.uiowa.edu?Subject=RE:%20%5BR%5D%20mkChar%20can%20be%20interrupted>
>>> Iowa City, IA 52242 WWW:
http://www.stat.uiowa.edu<http://www.stat.uiowa.edu/>
>>>
>>>
>>>
>> ______________________________________________
>> R-help at stat.math.ethz.ch<mailto:R-help at
stat.math.ethz.ch?Subject=RE:%20%5BR%5D%20mkChar%20can%20be%20interrupted>
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<http://www.r-project.org/posting-guide.html>
>>
>
> --
> Luke Tierney
>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel