Jean-Paul Calderone added the comment: The patch doesn't change the threading module, so I'm not sure if there's anything in particular you think is performance critical there. The places where it uses try/finally are:
* _Condition.wait. This performs operations on a mutex which are much slower than any overhead "with" might bring. It also has sleep calls in it to implement timeout support, so it's not going to be extremely fast in those cases anyway. I notice, however, that it executes a number of lines of code outside before setting up the try/finally statement, allowing for the possibility of a buggy deadlock should an exception (such as KeyboardInterrupt) occur before the try block begins. * _Event.set, which uses _Condition and so also deals with mutexes. * _Event.clear and _Event.wait, similarly. * Thread.__bootstrap, which writes to stderr and uses mutexes, so is already quite slow. (but this case probably isn't a candidate for conversion to with anyway) * Thread.__delete and Thread.join, - more mutexes and conditions. So there doesn't seem to be anything particularly performance critical here. You can argue that the slightly increased overhead of with would still be bad, even for things that are already slow (such as mutex manipulation), I suppose. In this case, measuring the difference would be a useful step to take. However, there's also the issue of correctness. A KeyboardInterrupt can arrive between any of these mutxes being acquired and the try/finally being set up. It can also arrive after the finally begins executing and before the mutex is actually released. In either case, this will result in a lock being held when it shouldn't be, which will probably lead to a deadlock. Converting to with to manipulate these mutexes (assuming the lock type has its context management methods implemented in C) will remove the possibility of these bugs occurring. ---------- nosy: +exarkun __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1941> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
