On Mon, Dec 31, 2012 at 5:24 PM, Nils Bruin <nbr...@sfu.ca> wrote: > On Dec 31, 5:15 pm, Robert Bradshaw <rober...@gmail.com> wrote: > > Looking at this more, this seems fine, as the un-initialized members are > > NULL before cinit completes, and set to null as dealloc progresses > > using Py_CLEAR. The traversal and clear functions ignore NULL members. > > Except that the Py_CLEAR executions could trigger cyclic GCs (for > instance because their deallocation could trigger weakref callbacks). >
True. > The object being deallocated should not be tracked at that point. Ah, what you're saying is that even though tp_traverse is "safe" to call, being tracked by gc implies that this object is safe to (mark for later) decref. Is that what you're thinking. Yeah, sticking an untrack there certainly seems safe. It looks like PyObject_GC_UnTrack is idempotent, so we don't have to track it before going up the dealloc stack. If this fixes it, I sense another Cython release around the corner... > I > really think that by default, a dealloc should first untrack its > object before anything else. You can try to argue from there whether > it's safe to deviate from that. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To post to this group, send email to sage-devel@googlegroups.com. > To unsubscribe from this group, send email to > sage-devel+unsubscr...@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
