[Lldb-commits] [PATCH] D69488: [LLDB][Python] fix another fflush issue on NetBSD
Lawrence D'Anna via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Sun Oct 27 23:09:56 PDT 2019
lawrence_danna marked 2 inline comments as done.
lawrence_danna added inline comments.
================
Comment at: lldb/packages/Python/lldbsuite/test/python_api/file_handle/TestFileHandle.py:854
files = list(i(sbf))
+ # delete them in reverse order, again because each is a borrow
+ # of the previous.
----------------
mgorny wrote:
> For the record, this doesn't really guarantee specific order of destruction. Generally, in Python code you shouldn't rely on destructors being called at all and close files manually. That's why `with` is commonly used with files.
The point is not to rely on the file being closed at a certain time. They point is that each file added to the list is a borrowed reference to the previous one, and we should not allow those references to become dangling by letting the older ones go to zero-references before the younger ones.
Now that I say it, I wonder if it was a bad idea to expose this kind of C++ object lifetime semantics to python programs.
I put in `GetFile` mainly so that in the case that a SBFile was a proxy of a python file, you could get the python file back.
It might be better to restrict it to that case, and return None instead of a borrowed file in other cases.
On the other hand, there's value in having a consistent API. Under the current semantics this just works:
```
print("foo", file=debugger.GetOutputFile().GetFile())
```
Overall I think I'd lean towards keeping GetFile the way it is, but I can see the argument for restricting it.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D69488/new/
https://reviews.llvm.org/D69488
More information about the lldb-commits
mailing list