#15149: Bug in pickling of toric varieties, II
-------------------------------------+-------------------------------------
Reporter: jkeitel | Owner:
Type: defect | Status: positive_review
Priority: major | Milestone: sage-6.0
Component: algebraic | Resolution:
geometry | Merged in:
Keywords: toric | Reviewers: Volker Braun
Authors: | Work issues:
Report Upstream: N/A | Commit:
Branch: | 15a41647c634421769963f6b6ccabe65c7907789
u/jkeitel/toric_pickling_2 | Stopgaps:
Dependencies: #15050 |
-------------------------------------+-------------------------------------
Comment (by nbruin):
I still think the current patch removes the symptom, but does not solve
the underlying reason: ToricVarieties don't pickle in a way that is robust
in the face of circular references. This is because ToricVarieties aren't
sufficiently initialized in the construction phase of their unpickling to
make their hash work. I don't know what guarantees pickling/unpickling
makes about what happens between objects being constructed and having
`setstate` called on them, but the circular references show that it isn't
guaranteed that nothing happens in between. The problem happens to be
triggered by circular references, but I don't think we have proof that
will even be the only case when it happens.
Anyway, circular references aren't forbidden and pickling in general has
been designed to have the means to deal with it. The next time someone
introduces circular references on toric varieties, we'll have the same
problem again. I'm sure ToricVarieties aren't the only data structures
that have this problem. Unless one pays specific attention to this problem
(or inherits from UniqueRepresentation!) one is likely to have this
problem.
I don't particular disagree with the fact that caches aren't pickled --
that may well be a good idea. However, I do think that
`ClearCacheOnPickle` is a really bad way of achieving that effect: it
actually wipes the caches, rather than remove them from the dictionary
that is submitted for pickling. That means that doing
`dumps(toric_variety)` changes the performance of subsequent behaviour!
Why not just put a custom `__reduce__` or `__getnewargs__` on
toricvarieties and solve the problem permanently? If you don't want to
pickle caches, you can easily have that as a corollary.
--
Ticket URL: <http://trac.sagemath.org/ticket/15149#comment:9>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
