Skip to content

stopping finalizers

9 messages · Thomas Lumley, Luke Tierney, Antonio, Fabio Di Narzo +2 more

Original
1 day later
Luke Tierney
# 
It might help if you could be more specific about what the issue is --
if they are out of scope why does it matter whether the finalizers
run?

Generically two approaches I can think of:

     you keep track of whenit is safe to fully run your finalizers and have
     your finalizers put the objects on a linked list if it isn't safe to
     run the finalizer now and clear the list each time you make a new one

     keep track of your objects with a weak list andturn them into strong
     references before your calls, then drop the list after.

I'm pretty sure we don't have a mechanism for temporarily suspending
running the finalizers but it is probably fairly easy to add if that
is the only option.

I might be able to think of other options with more details on the
issue.

Best,

luke
On Tue, 12 Feb 2013, Thomas Lumley wrote:

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Antonio, Fabio Di Narzo
    

    

      
      #
    

  


  

      
I'm not sure I got your problem right, but you can keep a named copy
of your not-to-be-finalized object as long as it needs to be around,
so it doesn't go out of scope too early.

Something like:
local({
   dontFinalizeMe <- obj
   ##
   ## code which creates copies, overwrites, and indirectly uses 'obj'
   ##
})

hth,
--
Antonio, Fabio Di Narzo,
Biostatistician
Mount Sinai School of Medicine, NY.

2013/2/12 Thomas Lumley <tlumley at uw.edu>:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        
      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
I would argue that addressing this at a generic R level is the wrong place (almost, see below) -- because this is about *specific* finalizers. You don't mind running other people 's finalizers because they don't mess up your connection. Therefore, I'd argue that primarily the approach should be in your DB driver to synchronize the calls - which is what you did by queueing.

In a sense a more general approach won't be any different - you will need at least a list of *specific* objects that should be deferred - it's either in your driver or in R. I'd argue that the design is much easier in the driver because you know which finalizers to register, whereas R has no concept of finalizer "classes" to group them. You can also do this much more easily in the driver since you know whether they need to be deferred and if they do, you can easily process the deferred once when you get out of your critical section.

Because of this difference between specific finalizers and all GC any R-side solution that doesn't register such finalizers in a special way will be inherently wasteful - as you pointed out in the discussion below - and thus I'd say it's more dangerous than helpful, because R can then lock itself out of memory even if not necessary.

So IMHO the necessary practical way to solve this at R level (if someone wanted to spend the time) would be to create "bags" of finalizers and use those when defining critical regions, something like (pseudocode)

add_fin_bag("myDB", obj1)
// ...
add_fin_bag("myDB", obj2)

critical_fin_section_begin("myDB")
// ... here no finalizers for objects in the bag can be fired
critical_fin_section_end("myDB")

Technically, the simple solution would be to simply preserve the bag in the critical region. However, this would not guarantee that the finalizers get fired at the end of the section even if gc occurred. I suspect it would be harder to guarantee that (other than running gc explicitly or performing explicit de-allocation after the finalizer was detected to be scheduled but not fired).

Cheers,
Simon

        
On Feb 14, 2013, at 3:12 PM, Thomas Lumley wrote:

        

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Hadley Wickham
    

    

      
      #
    

  


  

          

      
      
      
    

        
Isn't subset slightly too early to do this?  It would be slightly more
efficient for subset to return an object that creates the table when
you first attempt to modify it.

Hadley

  
    

      
      
    

  


  


      

    

    

      
      

        
      

    

    

      
      

        


  

        

      Hadley Wickham
    

    

      
      #
    

  


  

          

      
      
      
    

        
Cool - Is that faster than storing a column that just contains the
include indices?

            

      
      
      
    

        
Have you done any comparisons of monetdb vs sqlite - I'm interested to
know how much faster it is. I'm working on a package
(https://github.com/hadley/dplyr) that compiles R data manipulation
expressions into (e.g. SQL), and have been wondering if it's worth
considering a column-store like monetdb.

Hadley