[issue6615] multiprocessing logging support test

Changes by Vinay Sajip : -- resolution: accepted -> fixed status: pending -> closed ___ Python tracker ___ ___ Python-bugs-list mailing

[issue6615] multiprocessing logging support test

Changes by Florent Xicluna : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue6615] multiprocessing logging support test

Changes by Florent Xicluna : -- status: pending -> open versions: -Python 2.6, Python 3.1 ___ Python tracker ___ ___ Python-bugs-list

[issue6615] multiprocessing logging support test

Florent Xicluna added the comment: It should be closed now. -- priority: -> normal stage: -> committed/rejected status: open -> pending ___ Python tracker ___ _

[issue6615] multiprocessing logging support test

Vinay Sajip added the comment: > Since you "reversed()" the _handlerList, the following part need to be > changed: > > -_handlerList.insert(0, weakref.ref(handler, _removeHandlerRef)) > +_handlerList.append(weakref.ref(handler, _removeHandlerRef)) Corrected in r76509. Florent,

[issue6615] multiprocessing logging support test

flox added the comment: Thank you Vinay. Since you "reversed()" the _handlerList, the following part need to be changed: Index: Lib/logging/__init__.py === --- Lib/logging/__init__.py (revision 76508) +++ Lib/logging/__init__.

[issue6615] multiprocessing logging support test

Vinay Sajip added the comment: Changes checked into trunk (r76508) - very slightly different to flox's patch. Also made _handlers a WeakValueDictionary. -- ___ Python tracker __

[issue6615] multiprocessing logging support test

Changes by flox : Removed file: http://bugs.python.org/file15397/issue6615_weakref.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue6615] multiprocessing logging support test

flox added the comment: Small change to acquire the module lock before working on _handlerList. -- Added file: http://bugs.python.org/file15398/issue6615_weakref.diff ___ Python tracker

[issue6615] multiprocessing logging support test

Changes by flox : Removed file: http://bugs.python.org/file15396/issue6615_weakref.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue6615] multiprocessing logging support test

flox added the comment: Updated the patch with technical recommendations from Antoine. I kept the _handlerList as a list because "It allows handlers to be removed in reverse of order initialized." And some tests are needed to outline the change. -- Added file: http://bugs.python.org/f

[issue6615] multiprocessing logging support test

Antoine Pitrou added the comment: Some quick comments on your patch (not an in-depth review): - you should add some tests for the problem you're trying to solve - using __del__ when you have a weakref is counter-productive; use the weakref's optional callback instead - if you remove arbitrary el

[issue6615] multiprocessing logging support test

flox added the comment: yep... patch was not clean. Sorry :( I changed it. It passes the 21 tests of the test_logging suite. And the count of references decreases with the test: >>> import logging >>> handler = logging.Handler() >>> handler = logging.Handler() -- Added file: http://b

[issue6615] multiprocessing logging support test

Changes by flox : Removed file: http://bugs.python.org/file15395/issue6615_weakref.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue6615] multiprocessing logging support test

Vinay Sajip added the comment: > With the patch attached, if the handler is not referenced anywhere, it > is closed. > However named handlers are not closed (because of hard reference in > _handlers dictionary). I haven't tried it yet, but does the patch actually work? You seem to have self_w

[issue6615] multiprocessing logging support test

flox added the comment: I would think to use weak references in order to prevent such leaks. With the patch attached, if the handler is not referenced anywhere, it is closed. However named handlers are not closed (because of hard reference in _handlers dictionary). -- nosy: +flox Added

[issue6615] multiprocessing logging support test

Vinay Sajip added the comment: > removing from a handler), it's removed from the list and would not cause a s/handler/logger/ -- ___ Python tracker ___

[issue6615] multiprocessing logging support test

Vinay Sajip added the comment: > Why is this exactly? Why do you want to keep handlers until shutdown > rather than dispose of them when they aren't used anymore? Typically handlers are only instantiated when being added to loggers, and loggers live for the lifetime of the process so those ha

[issue6615] multiprocessing logging support test

Antoine Pitrou added the comment: > Handler.__init__ no longer adds the handler instance to the _handlers > map unconditionally, but still adds it to the _handlerList array. The > only place this array is actually used is in the shutdown() API, which > is registered to be run via atexit. It flus

[issue6615] multiprocessing logging support test

Vinay Sajip added the comment: > In general it would be nice if logging were more conservative (or > cautious) when it comes to keeping objects persistent. It is too easy to > fall into a trap and experience memory leaks. I've checked in a change into trunk today which might improve matters.

[issue6615] multiprocessing logging support test

Jesse Noller added the comment: Yeah, I should have checked the tearDown stuff in the logging test suite -- ___ Python tracker ___ ___

[issue6615] multiprocessing logging support test

Antoine Pitrou added the comment: > Yes, test_logging has a serious tearDown() method to wipe installed > handlers. In general it would be nice if logging were more conservative (or cautious) when it comes to keeping objects persistent. It is too easy to fall into a trap and experience memory l

[issue6615] multiprocessing logging support test

Amaury Forgeot d'Arc added the comment: Yes, test_logging has a serious tearDown() method to wipe installed handlers. -- ___ Python tracker ___ __

[issue6615] multiprocessing logging support test

Antoine Pitrou added the comment: >From a quick command-line attempt, it seems that logging is the culprit: >>> handler = logging.Handler() [64370 refs] >>> handler = logging.Handler() [64383 refs] >>> handler = logging.Handler() [64396 refs] -- nosy: +pitrou, vinay.sajip

[issue6615] multiprocessing logging support test

Amaury Forgeot d'Arc added the comment: Are these leaks caused by the test, or revealed by it? -- nosy: +amaury.forgeotdarc ___ Python tracker ___ ___

[issue6615] multiprocessing logging support test

Jesse Noller added the comment: I've commented out the test (therefore, reopening this) the test introduces a pretty bad refleak problem. Need to debug. -- resolution: fixed -> accepted status: closed -> open ___ Python tracker

[issue6615] multiprocessing logging support test

Jesse Noller added the comment: merged to py3k in r76439 -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Py

[issue6615] multiprocessing logging support test

Jesse Noller added the comment: patch committed to trunk in r76438 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue6615] multiprocessing logging support test

Changes by Ask Solem : -- keywords: +patch Added file: http://bugs.python.org/file15375/6615.patch ___ Python tracker ___ ___ Python-bu

[issue6615] multiprocessing logging support test

Changes by Jesse Noller : -- assignee: -> jnoller ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue6615] multiprocessing logging support test

New submission from OG7 : There is an additional test for multiprocessing's logging support here: http://code.google.com/p/python-multiprocessing/issues/detail?id=18 (disregard the fix, it is only needed for the backport). -- components: Library (Lib) messages: 91163 nosy: OG7, jnoller s