Nick Coghlan <[email protected]> added the comment:
It's still the same problem - the underlying issue is that the with statement
machinery doesn't currently mask signals in the main thread while __enter__ and
__exit__ are running, so __enter__ and __exit__ methods written in Python are
also at risk of being interrupted at an inopportune point.
This means that even "with closing(open('filename')) as f: ..." is more at risk
of leaving the file open until __del__ cleans it up than the version that calls
open() directly.
So if this a concern that an application needs to worry about, then it
currently needs to adopt a more complicated execution structure where:
1. The main thread launches a subthread that actually does all the work.
2. The main thread immediately drops into "active_thread.join()" (which can be
interrupted by Ctrl-C)
Unfortunately, this scheme *doesn't* work for applications where the
application itself needs to detect and handling signals other than Ctrl-C.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue34157>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com