Oliver Schoenborn wrote: > Oh no, absolutely not! The objects are finaly-izated only for the frame > where created. This is ensured because the cleaner uses a stack (unrelated > to the frame stack), one item in the stack per function call. You will see > this clearly if you look at the latest detscope.py. b is cleaned up upon > return from g, and a will be cleaned up only upon return from f. While I understand your implementation, I'm uncertain how much of it you consider normative, and how much is implementation detail. For example, is the order in which the finally-izers are called significant or not? Or, coming back to my original question: It appears that *not* all objects registered with the cleaner are destroyed when the function returns. This brings me back to my original question: As not all objects are finally-ized at the end of the function, then *which* objects precisely are finally-ized? Let me try guess an answer: At the end of a scope-guarded function, all need-finally-ization objects are finally-ized that have been created since the function was invoked, and which haven't yet been finally-ized. Taking threads into account, this definition is probably not what you want: likely, you want to see only those objects finally-ized, that have been created in the context of the thread in which the function was invoked. Is that correct? In particular, what happens with need-finally-ization objects which whose constructor call does not directly appear in a scope-guarded function? Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4