| 164 | | Keep in mind that in principle, singular code can get executed in rather awkward moments, possibly as part of clean-ups of circular garbage and call-backs on weakref cleanup, where equality might be tested of objects that are soon to be deallocated themselves. |
| | 164 | It looks suspicious to me that `sage.libs.singular.ring.singular_ring_delete` does do a careful dance to zero out the `currRing` variable but doesn't seem to care about `currRngHdl`. I also find it worrying that there apparently is a refcount system right on the ring structures (as you can see above) and yet in `singular_ring_delete` a separate refcounting dict is used. One would think the same refcounting system should be borrowed by `singular_ring_new` and `singular_ring_delete`. It looks to me the code above thinks that by increasing `...uring.ref` the reference is protected, but `singular_ring_delete` doesn't seem to take into account this refcount. It could well be that I'm misinterpreting the code and that this is all perfectly safe, though. |
| | 165 | |
| | 166 | Libsingular specialists: Keep in mind that in principle, singular code can get executed in rather awkward moments, possibly as part of clean-ups of circular garbage and call-backs on weakref cleanup, where equality might be tested of objects that are soon to be deallocated themselves. |
