On Wednesday, December 5, 2018 at 8:43:06 AM UTC-8, Jeroen Demeyer wrote: > > On 2018-12-05 14:54, Simon King wrote: > > o Mild problem: If there is an external strong reference to, say, > > f, then it is possible that Q becomes garbage collected anyway, > > and we would end up with an invalid map. > > That is one of the things that I would like to fix: maps and actions > should have strong references to their (co)domains. On the other hand, > the coercions and actions should be sufficiently weakly referenced to > prevent memory leaks but not too weakly referenced to keep them alive > when needed. This will rely on #26811. >
I think this should work fine for "standard" coercion maps A->B, where B is an object constructed from A, so A is referenced by B anyway. But there we didn't need weak references to the domain anyway. I suspect there might be problems for coercion maps c: A->C, where C is a longer-lived structure (SR, Qbar, or CC for instance). Presently, "c" is stored on C. It has to be stored there with a strong reference, to prevent c from being collected. If c carries a strong reference to A, then now the life span of A is bounded below by the lifespan to C. I think you were thinking of limiting the life span of c via referencing it via a "MultiWeakRef" from both A and C. However, with the scenario above, A has its life span already bounded below by C anyway, so the "MultiWeakRef" never gets to work its magic. (it's nice to see a memory leak that for once does not come from the UniqueRepresentation cache) Again, it's ugly, but carrying a weakref to the domain (or no reference to the domain at all!) is not fundamentally a performance problem for coercion maps: Whenever a coercion is called, we already know what the domain and codomain are, because that's how we looked up the coercion in the first place! It may be a performance problem in setting up coercions, because of all the shenanigans with stripping off the domain, and it's easy to write code that does have a penalty if you don't explicitly make sure to use your a priori knowledge of the domain. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
