[issue3125] test_multiprocessing causes test_ctypes to fail

Ask Solem added the comment: As no one has been able to confirm that this is still an issue, I'm closing it as "out of date". The issue can be reopened if necessary. -- resolution: accepted -> out of date status: open -> closed ___ Python tracker <

[issue3125] test_multiprocessing causes test_ctypes to fail

Mark Lawrence added the comment: Is this still a problem or can this be closed, given r65883? -- components: +Tests nosy: +BreamoreBoy stage: -> patch review type: -> behavior ___ Python tracker _

[issue3125] test_multiprocessing causes test_ctypes to fail

Changes by Ask Solem : -- nosy: +asksol ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/m

[issue3125] test_multiprocessing causes test_ctypes to fail

Jesse Noller <[EMAIL PROTECTED]> added the comment: Just to confirm this issue was resolved enough to be lowered from a blocker - I ran py3k tests in a loop for about 2+ hours. The fix applied in r65883 works well enough that the current implementation does not need to change. -- prio

[issue3125] test_multiprocessing causes test_ctypes to fail

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Jesse, It seems that the patch was merged into py3k by r65883. The trick was from pickle import _Pickler as Pickler to get the subclassable python implementation. The only remaining point is the handling of dictionary views (see reb

[issue3125] test_multiprocessing causes test_ctypes to fail

Jesse Noller <[EMAIL PROTECTED]> added the comment: Working on the py3k patch now, bumping to rel. blocker -- priority: -> release blocker ___ Python tracker <[EMAIL PROTECTED]> _

[issue3125] test_multiprocessing causes test_ctypes to fail

Jesse Noller <[EMAIL PROTECTED]> added the comment: Here is a proposed patch for py3k generated from an svn merge of amaury's patch into py3k. This is currently blocked due to issue3385. Added file: http://bugs.python.org/file10911/py3k_no_copyreg.patch ___

[issue3125] test_multiprocessing causes test_ctypes to fail

Jesse Noller <[EMAIL PROTECTED]> added the comment: Amaury's patch is applied in r65016 to trunk, all tests pass This needs to be merged forward, and then Lib/multiprocessing/managers.py in py3k has to have: for view_type in view_types: copy_reg.pickle(view_type, rebuild_as_lis

[issue3125] test_multiprocessing causes test_ctypes to fail

Jesse Noller <[EMAIL PROTECTED]> added the comment: Tests are back on as of r64663 on trunk. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]>

[issue3125] test_multiprocessing causes test_ctypes to fail

Jesse Noller <[EMAIL PROTECTED]> added the comment: I closed the wrong bug -- resolution: fixed -> accepted status: closed -> open ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3125] test_multiprocessing causes test_ctypes to fail

Jesse Noller <[EMAIL PROTECTED]> added the comment: Sorry - I've been sick and overly busy this week, the mp issues are on my asap pile On Jun 26, 2008, at 7:17 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED] > wrote: > > Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > > Jesse: pi

[issue3125] test_multiprocessing causes test_ctypes to fail

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Jesse: ping? ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing

[issue3125] test_multiprocessing causes test_ctypes to fail

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Here is a patch that implements a custom pickler for multiprocessing.forking. copy_reg has been completely replaced by calls to ForkingPickler.register(): the global registry is not modified. Added file: http://bugs.python.org/file10661

[issue3125] test_multiprocessing causes test_ctypes to fail

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Why not use a custom Pickler in this case? It would to be enough to copy the self.dispatch dictionary, and add the special types there. ___ Python tracker <[EMAIL PROTECTED]>

[issue3125] test_multiprocessing causes test_ctypes to fail

roudkerk <[EMAIL PROTECTED]> added the comment: > I am not sure to understand. Can you elaborate? > How is memory management different between windows and unix? Removing the "if win32" bits will not make shared ctypes objects picklable on unix. Even on windows there are only picklable in the co

[issue3125] test_multiprocessing causes test_ctypes to fail

Changes by Jesse Noller <[EMAIL PROTECTED]>: -- assignee: -> jnoller ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list ma

[issue3125] test_multiprocessing causes test_ctypes to fail

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: roudkerk wrote: > Yes, on Windows pickling is needed to pass data to a child process. In > other contexts these objects are NOT picklable because you would have to > worry about garbage collection of the original object before the copy

[issue3125] test_multiprocessing causes test_ctypes to fail

Jesse Noller <[EMAIL PROTECTED]> added the comment: Thomas' patch applied and runs clean for me - does anyone have a problem with me submitting it? ___ Python tracker <[EMAIL PROTECTED]> _

[issue3125] test_multiprocessing causes test_ctypes to fail

Thomas Heller <[EMAIL PROTECTED]> added the comment: roudkerk schrieb: > roudkerk <[EMAIL PROTECTED]> added the comment: > > This patch to sharedctypes should fix the problem by adding a > __reduce_ex__() method to a shared ctype object instead of using copy_reg. I can confirm that the patch fi

[issue3125] test_multiprocessing causes test_ctypes to fail

roudkerk <[EMAIL PROTECTED]> added the comment: > But why this is win32 specific? > > Is it because windows cannot fork(), so data has to be copied through > the pickle mechanism? > In this case let's remove the "if win32" statement, and always execute > the body. Yes, on Windows pickling is ne

[issue3125] test_multiprocessing causes test_ctypes to fail

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: But why this is win32 specific? Is it because windows cannot fork(), so data has to be copied through the pickle mechanism? In this case let's remove the "if win32" statement, and always execute the body. -- nosy: +amaury.forge

[issue3125] test_multiprocessing causes test_ctypes to fail

roudkerk <[EMAIL PROTECTED]> added the comment: This patch to sharedctypes should fix the problem by adding a __reduce_ex__() method to a shared ctype object instead of using copy_reg. -- keywords: +patch Added file: http://bugs.python.org/file10652/sharedctypes.py.patch ___

[issue3125] test_multiprocessing causes test_ctypes to fail

Thomas Heller <[EMAIL PROTECTED]> added the comment: > Adam Olsen <[EMAIL PROTECTED]> added the comment: > > I see no common symbols between #3102 and #3092, so unless I missed > something, they shouldn't be involved. > > I second the notion that multiprocessing's use of pickle is the > trigger

[issue3125] test_multiprocessing causes test_ctypes to fail

Changes by Jesse Noller <[EMAIL PROTECTED]>: -- nosy: +roudkerk ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing

[issue3125] test_multiprocessing causes test_ctypes to fail

Adam Olsen <[EMAIL PROTECTED]> added the comment: I see no common symbols between #3102 and #3092, so unless I missed something, they shouldn't be involved. I second the notion that multiprocessing's use of pickle is the triggering factor. Registering so many types is ugly, and IMO it shouldn't

[issue3125] test_multiprocessing causes test_ctypes to fail

Thomas Heller <[EMAIL PROTECTED]> added the comment: Adam Olsen schrieb: > Thomas, do you have a specific command to reproduce this? It runs fine > if I do "./python -m test.regrtest -v test_multiprocessing test_ctypes". > That's with amaury's patch from 3100 applied. It seems the failure only

[issue3125] test_multiprocessing causes test_ctypes to fail

Jesse Noller <[EMAIL PROTECTED]> added the comment: Sorry, the first link should have been: http://bugs.python.org/issue3093 ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3125] test_multiprocessing causes test_ctypes to fail

Jesse Noller <[EMAIL PROTECTED]> added the comment: Sorry Adam, I was referencing: http://bugs.python.org/issue3102 Also, it is possible issue: http://bugs.python.org/issue3102 is related? ___ Python tracker <[EMAIL PROTECTED]>

[issue3125] test_multiprocessing causes test_ctypes to fail

Adam Olsen <[EMAIL PROTECTED]> added the comment: Jesse, can you be more specific? Thomas, do you have a specific command to reproduce this? It runs fine if I do "./python -m test.regrtest -v test_multiprocessing test_ctypes". That's with amaury's patch from 3100 applied.

[issue3125] test_multiprocessing causes test_ctypes to fail

Thomas Heller <[EMAIL PROTECTED]> added the comment: IMO this problem occurs because multiprocessing registers pickling support for ctypes, but the ctypes in trunk already has support for pickling. ___ Python tracker <[EMAIL PROTECTED]>

[issue3125] test_multiprocessing causes test_ctypes to fail

Jesse Noller <[EMAIL PROTECTED]> added the comment: Adam, is this due to the c-code tainting you pointed out earlier? ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3125] test_multiprocessing causes test_ctypes to fail

Changes by Adam Olsen <[EMAIL PROTECTED]>: -- nosy: +Rhamphoryncus, jnoller ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-l

[issue3125] test_multiprocessing causes test_ctypes to fail

New submission from Thomas Heller <[EMAIL PROTECTED]>: test_ctypes, when run after testmultiprocessing, fails: ... == ERROR: test_simple (ctypes.test.test_pickling.PickleTest)