This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author njs
Recipients deleted0524, ncoghlan, njs, yselivanov
Date 2017-05-23.23:26:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Right, fixing this bug alone can't make programs control-C safe in general. But there exist techniques to make __enter__/__exit__ methods safe WRT control-C, and if we fix this bug *and* apply those techniques then you can get some meaningful guarantees.

For example, threading.Lock's __enter__ and __exit__ methods are written in C, so they are guaranteed to happen atomically WRT to control-C. Right now, it's possible for a 'with lock: ...' to raise KeyboardInterrupt with the lock still held, which is surprising and not what we would like. If this bug were fixed, then it would be guaranteed that the lock was always released.

(And I originally discovered this while implementing control-C handling in trio, which is pure-Python but also has a way to protect __(a)enter__/__(a)exit__ methods against control-C. ...though that won't be 100% reliable until bpo-12857 or similar is fixed. See for exhaustive details.)
Date User Action Args
2017-05-23 23:26:57njssetrecipients: + njs, ncoghlan, yselivanov, deleted0524
2017-05-23 23:26:57njssetmessageid: <>
2017-05-23 23:26:57njslinkissue29988 messages
2017-05-23 23:26:57njscreate