#715: Parents probably not reclaimed due to too much caching
-------------------------------------------------------------------+--------
       Reporter:  robertwb                                         |         
Owner:  somebody                                 
           Type:  defect                                           |        
Status:  positive_review                          
       Priority:  major                                            |     
Milestone:  sage-5.4                                 
      Component:  coercion                                         |    
Resolution:                                           
       Keywords:  weak cache coercion Cernay2012                   |   Work 
issues:                                           
Report Upstream:  N/A                                              |     
Reviewers:  Jean-Pierre Flori, Simon King, Nils Bruin
        Authors:  Simon King, Jean-Pierre Flori                    |     Merged 
in:                                           
   Dependencies:  #9138, #11900, #11599, to be merged with #11521  |      
Stopgaps:                                           
-------------------------------------------------------------------+--------
Changes (by nbruin):

  * status:  needs_review => positive_review


Comment:

 '''safer.patch''': `sage/structure/coerce_dict.pyx`
 {{{
       # This is to cope with a potential racing condition - if garbage
       # collection and weakref callback happens right between the
       # "if (isinstance(r1,..." and the "del", then the previously
       # existing entry might already be gone.
 }}}
 No, there is no such racing condition. You are holding references
 `k1,k2,k3`. You have just looked up the weakreference `r1,r2,r3` to these
 keys
 and checked that the weakrefs are still alive (and hence that it's not the
 case
 that one of the `ki` is just a new element that happens to have the same
 id as a
 now-deceased previous key element in the dict).
 Since you are holding references, they cannot die in between, so I don't
 think
 the
 {{{
     del self._refcache[<size_t><void *>k1,<size_t><void *>k2,<size_t><void
 *>k3]
 }}}
 needs to be quarded.

 It won't hurt, though, and this code will be optimized anyway, so no
 effect on
 the review.

 Concerning `next_odd_prime`: I'm pretty sure we're keeping a list of
 primes
 somewhere in sage. We might want to look in there rather than have this
 snippet
 here. Again, not hurtful to do it this way.

 '''trac_715_specification.patch''': One line fuzz in application. Do we
 care?

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/715#comment:220>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sage-trac?hl=en.

Reply via email to