2011/6/2 Francois Bissey <francois.bis...@canterbury.ac.nz>:
>> Em 1 de junho de 2011 18:22, Paulo César Pereira de Andrade
>>
>> <paulo.cesar.pereira.de.andr...@gmail.com> escreveu:
>> > If I understand it correctly, at least for this particular case:
>> >
>> >
>> > sage/libs/singular/groebner_strategy.pyx:GroebnerStrategy(SageObject)._pa
>> > rent =>
>> > sage/rings/polynomial/multi_polynomial_libsingular.pyx:MPolynomialRing_l
>> > ibsingular(MPolynomialRing_generic)
>> >
>> > and the _parent field has a __dealloc__ as:
>> > singular_ring_delete(self._ring) while the GroebnerStrategy
>> > __dealloc__ deferences _parent._ring.
>> >
>> > So, again if I understand correctly, the crash is happening because
>> > MPolynomialRing_libsingular:__deallocate__ should be called
>> > after pyx:GroebnerStrategy:__deallocate__, but in python 2.7
>> > this is not happening, as the order is not guaranteed, and
>> > apparently just happens to be in the correct order with
>> > python 2.6.
>>
>> Sorry for replying to myself, but actually, it should be quite
>> simple to have it functional, just that it must be done in a case
>> by case approach. Something like:
>>
>> GroebnerStrategy():
>> __new__:
>> ...
>> the_ring_handle = ...
>> incref(the_ring_handle)
>> __del__:
>> ...
>> decref(the_ring_handle)
>> del the_ring_handle ## requirement of this depends on semantics
>>
>> MPolynomialRing_libsingular():
>> __new__:
>> ...
>> the_ring_ptr = ...
>> __del__:
>> if (refcnt(self) <= 0) ## how to do this in python? check if
>> == 1? or do not use python reference counter?
>> free(the_ring_ptr)
>>
>> This should be easy for python internal experts to
>> implement (I can try to experiment with that, but I do
>> not know much of python and only do mark&sweep :-)
>>
> Quoting Volker:
> Just to clarify, right now Cython extension classes do not call the Python
> destructor __del__ upon finalization, so Sage can't rely on this mechanism.
> I'm
> not quite sure if it is an intentional thing or if the Cython devs just
> haven't gotten around to implementing it.
I started doing some experiments mostly for the sake of testing :-)
But my python/cython kung-fu is too weak, as well as general
knowledge of the sage "object model" and my experiments
ended in the same backtrace, so I did not work on the correct
point or something, and for now I give up.
> So we need cython to catch up with that one.
Cython probably will also not understand the context of
memory being allocated and released outside its control.
The proper approach should be to ensure that python does
not see reachable sage objects as a looping cycle with 0
references, and then "breaks" the cycle in unpredictable
ways.
In my basic understanding of sage classes, it should
release things somewhat like:
>>> del a
===>
list = <set of objects reachable from a>
while length(list):
foreach item in list:
if item._parent == item:
<blame the user>
item._parent = None
test = map(list, _._parent == item)
if length(test) == 0:
item.__dealloc__()
remove(list, item)
> Francois
Paulo
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
