Vladimir Marangozov wrote:
Christian Tismer wrote:
Vladimir Marangozov wrote:
[yup, good looking patch]
where _PyTrash_deposit_object returns 0 on success, -1 on failure. This gives another last chance to the system to finalize the object, hoping that the stack won't overflow. :-)
My point is that it is better to control whether _PyTrash_deposit_object succeeds or not (and it may fail because of PyList_Append). If this doesn't sound acceptable (because of the possible stack overflow) it would still be better to abort in _PyTrash_deposit_object with an exception "stack overflow on recursive finalization" when PyList_Append fails. Leaving it unchecked is not nice -- especially in such extreme situations.
You bet that I *would* raise an exception if I could. Unfortunately the destructors have no way to report an error, and they are always called in a context where no error is expected (Py_DECREF macro). I believe this *was* quite ok, until __del__ was introduced. After that, it looks to me like a design flaw. IMHO there should not be a single function in a system that needs heap memory, and cannot report an error.
Currently, if something fails, the object is not finalized (leaking memory). Ok, so be it. What's not nice is that this happens silently which is not the kind of tolerance I would accept from the Python runtime.
Yes but what can I do? This isn't worse than before. deletion errors die silently, this is the current concept. I don't agree with it, but I'm not the one to change policy. In that sense, trashcan was just compliant to a concept, without saying this is a good concept. :-)
As to the bug: it's curious that, as Mark reported, without the trashcan logic, things seem to run fine. The trashcan seems to provoke (ok, detect ;) some erroneous situation. I'd expect that if the trashcan macros are implemented as above, the crash will go away (which wouldn't solve the problem and would obviate the trashcan in the first place :-)
I think trashcan can be made *way* smarter: Much much more better would be to avoid memory allocation in trashcan at all. I'm wondering if that would be possible. The idea is to catch a couple of objects in an earlier recursion level, and use them as containers for later objects-to-be-deleted. Not using memory at all, that's what I want. And it would avoid all messing with errors in this context. I hate Java dieing silently, since it has not enough memory to tell me that it has not enough memory :-) but-before-implementing-this-*I*-will-need-to-become-*way*-smarter - ly y'rs - chris -- Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com