Message322013
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. |
|
Date |
User |
Action |
Args |
2018-07-20 15:17:51 | ncoghlan | set | recipients:
+ ncoghlan, rhettinger, jwilk |
2018-07-20 15:17:51 | ncoghlan | set | messageid: <1532099871.48.0.56676864532.issue34157@psf.upfronthosting.co.za> |
2018-07-20 15:17:51 | ncoghlan | link | issue34157 messages |
2018-07-20 15:17:51 | ncoghlan | create | |
|