Vinay Sajip <vinay_sa...@yahoo.co.uk> added the comment:
The other alternative would be to lock around callHandlers(). With the change you propose to addHandler/removeHandler, there are no errors, but the output of your test program is (with the lock acquisition/release in place): Thread finished after 468 iterations Thread finished after 488 iterations Thread finished after 476 iterations Thread finished after 462 iterations If the lock acquisition/release is removed from addHandler/removeHandler, then there are still no errors, and the output is: Thread finished after 479 iterations Thread finished after 453 iterations Thread finished after 468 iterations Thread finished after 469 iterations If I leave addHandler/removeHandler as they were and add locking around callHandlers(), there are no errors and the output is: Thread finished after 566 iterations Thread finished after 608 iterations Thread finished after 612 iterations Thread finished after 605 iterations This seems to suggest that locking around callHandlers() is better (more performant) than the copying of handler lists involved in your suggestion. Any comments on that? Also it will work in non-GIL environments like Jython/IronPython. The callHandlers() locking will of course add a cost even for those situations where handlers aren't added and removed in multi-threading scenarios, but I haven't benchmarked it yet. It's generally not good practice to add/remove handlers willy-nilly in threads, though of course it's not forbidden (e.g. the configuration functionality allows a thread to listen for configuration changes at runtime and then reconfigure logging, which adds/removes handlers in the thread. However, loggers are disabled while the reconfiguration is in progress, and some loss of messages would be expected to be tolerable in such a case). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35185> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
